Merge remote-tracking branch 'origin/main' into rien/remove-worker-executor-dead-code

Author: mpkorstanje

documentation/modules/ROOT/pages/writing-tests/assumptions.adoc

@@ -16,10 +16,26 @@ references.
 
 All JUnit Jupiter assumptions are static methods in the `{Assumptions}` class.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/AssumptionsDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/AssumptionsDemo.kt[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`

documentation/modules/ROOT/pages/writing-tests/dynamic-tests.adoc

@@ -76,10 +76,26 @@ For demonstration purposes, the `dynamicNodeSingleTest()` method generates a sin
 `DynamicTest` instead of a stream, and the `dynamicNodeSingleContainer()` method generates
 a nested hierarchy of dynamic tests utilizing `DynamicContainer`.
 
-[source,java]
+[tabs]
+====
+Java::
++
+--
+[source,java,indent=0]
 ----
 include::example$java/example/DynamicTestsDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/DynamicTestsDemo.kt[tags=user_guide]
+----
+--
+====
 
 [[named-support]]
 == Dynamic Tests and Named
@@ -90,10 +106,26 @@ shown in the first example below. The second example takes it one step further a
 to provide the code block that should be executed by implementing the `Executable`
 interface along with `Named` via the `NamedExecutable` base class.
 
-[source,java]
+[tabs]
+====
+Java::
++
+--
+[source,java,indent=0]
 ----
 include::example$java/example/DynamicTestsNamedDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/DynamicTestsNamedDemo.kt[tags=user_guide]
+----
+--
+====
 
 [[uri-test-source]]
 == URI Test Sources for Dynamic Tests
@@ -138,10 +170,26 @@ xref:writing-tests/parallel-execution.adoc[parallel execution]. You can configur
 `ExecutionMode` by using the `dynamicTest(Consumer)` and `dynamicContainer(Consumer)`
 factory methods as illustrated by the following example.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/DynamicTestsDemo.java[tags=execution_mode]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/DynamicTestsDemo.kt[tags=execution_mode]
+----
+--
+====
 
 Executing the above test factory method results in the following test tree and execution
 modes:

documentation/modules/ROOT/pages/writing-tests/exception-handling.adoc

@@ -26,10 +26,26 @@ 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.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/exception/UncaughtExceptionHandlingDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/exception/UncaughtExceptionHandlingDemo.kt[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
@@ -59,10 +75,26 @@ In the following example, the `failsDueToUncaughtAssertionError()` method throws
 `AssertionError`. Since the exception is not caught within the test method, JUnit Jupiter
 will mark the test as failed.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/exception/FailedAssertionDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/exception/FailedAssertionDemo.kt[tags=user_guide]
+----
+--
+====
 
 [[expected]]
 == Asserting Expected Exceptions
@@ -81,10 +113,26 @@ type of the thrown exception but also its subclasses, making it suitable for mor
 generalized exception handling tests. The `assertThrows()` assertion method returns the
 thrown exception object to allow performing additional assertions on it.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/exception/ExceptionAssertionDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/exception/ExceptionAssertionDemo.kt[tags=user_guide]
+----
+--
+====
 
 [[expected-assertThrowsExactly]]
 === Using `assertThrowsExactly()`
@@ -95,10 +143,26 @@ exception type. This is useful when precise exception handling behavior needs to
 validated. Similar to `assertThrows()`, the `assertThrowsExactly()` assertion method also
 returns the thrown exception object to allow performing additional assertions on it.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/exception/ExceptionAssertionExactDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/exception/ExceptionAssertionExactDemo.kt[tags=user_guide]
+----
+--
+====
 
 [[not-expected]]
 == Asserting That no Exception is Expected
@@ -109,10 +173,26 @@ _not_ thrown for a given code block within a test method. The `assertDoesNotThro
 assertion can be used when you want to verify that a particular piece of code does not
 throw any exceptions.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/exception/AssertDoesNotThrowExceptionDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/exception/AssertDoesNotThrowExceptionDemo.kt[tags=user_guide]
+----
+--
+====
 
 NOTE: Third-party assertion libraries often provide similar support. For example, AssertJ
 has `assertThatNoException().isThrownBy(() -> ...)`. See also:

documentation/modules/ROOT/pages/writing-tests/nested-tests.adoc

@@ -5,11 +5,27 @@ 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
+[tabs]
+====
+Java::
++
+--
+[source,java,indent=0]
 ----
 include::example$java/example/TestingAStackDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/TestingAStackDemo.kt[tags=user_guide]
+----
+--
+====
 
 When executing this example in an IDE, the test execution tree in the GUI will look
 similar to the following image.
@@ -39,10 +55,26 @@ class is parameterized.
 The following example illustrates how to combine `@Nested` with `@ParameterizedClass` and
 `@ParameterizedTest`.
 
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
 ----
 include::example$java/example/ParameterizedClassDemo.java[tags=nested]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/ParameterizedClassDemo.kt[tags=nested]
+----
+--
+====
 
 Executing the above test class yields the following output:
 

documentation/modules/ROOT/pages/writing-tests/repeated-tests.adoc

@@ -8,13 +8,32 @@ desired. Each invocation of a repeated test behaves like the execution of a regu
 The following example demonstrates how to declare a test named `repeatedTest()` that
 will be automatically repeated 10 times.
 
+[tabs]
+====
+Java::
++
+--
 [source,java]
 ----
 @RepeatedTest(10)
 void repeatedTest() {
 	// ...
 }
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin]
+----
+@RepeatedTest(10)
+fun 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
@@ -125,10 +144,26 @@ INFO: About to execute repetition 4 of 5 for repeatedTestInGerman
 INFO: About to execute repetition 5 of 5 for repeatedTestInGerman
 ....
 
-[source,java]
+[tabs]
+====
+Java::
++
+--
+[source,java,indent=0]
 ----
 include::example$java/example/RepeatedTestsDemo.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/RepeatedTestsDemo.kt[tags=user_guide]
+----
+--
+====
 
 When using the `ConsoleLauncher` with the unicode theme enabled, execution of
 `RepeatedTestsDemo` results in the following output to the console.

documentation/modules/ROOT/pages/writing-tests/test-classes-and-methods.adoc

@@ -41,11 +41,27 @@ lifecycle methods. For further information on runtime semantics, see
 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].
 
+.A standard test class
+[tabs]
+====
+Java::
++
+--
 [source,java,indent=0]
-.A standard Java test class
 ----
 include::example$java/example/StandardTests.java[tags=user_guide]
 ----
+--
+
+Kotlin::
++
+--
+[source,kotlin,indent=0]
+----
+include::example$kotlin/example/kotlin/StandardTests.kt[tags=user_guide]
+----
+--
+====
 
 It is also possible to use Java `record` classes as test classes as illustrated by the
 following example.

documentation/modules/ROOT/partials/release-notes/release-notes-6.1.0-M2.adoc

@@ -47,6 +47,8 @@ repository on GitHub.
 * Recursive updates are now supported when using `computeIfAbsent(K, Function, Class)` in
   the `ExtensionContext.Store`, providing parity with the deprecated
   `getOrComputeIfAbsent(K, Function, Class)` method.
+* Include index of `@ClassTemplate`/`@ParameterizedClass` invocations in test names in
+  legacy XML reports to make them unique
 
 [[v6.1.0-M2-junit-jupiter-deprecations-and-breaking-changes]]
 ==== Deprecations and Breaking Changes