Skip to content

Commit 5b48931

Browse files
Add Kotlin snippets for ten User Guide sections (#5590)
Add tabbed Java/Kotlin code examples to ten documentation pages, continuing the effort started in #5316 and #5432. Pages updated (Writing Tests): - Built-in Extensions (@tempdir, @autoclose, Locale/TimeZone, SystemProperty) - Conditional Test Execution - Display Names - Annotations - Timeouts - Test Interfaces and Default Methods Pages updated (Extensions): - Parameter Resolution - Keeping State in Extensions - Test Lifecycle Callbacks - Registering Extensions --------- Signed-off-by: Anton.Yalyshev <yalishev.ant@gmail.com> Co-authored-by: Marc Philipp <mail@marcphilipp.de>
1 parent f380e75 commit 5b48931

47 files changed

Lines changed: 3214 additions & 35 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

documentation/modules/ROOT/pages/extensions/keeping-state-in-extensions.adoc

Lines changed: 73 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -43,34 +43,82 @@ available for backward compatibility.
4343
An example implementation of `AutoCloseable` is shown below, using an `HttpServer`
4444
resource.
4545

46-
[source,java,indent=0]
4746
.`_HttpServer_` resource implementing `_AutoCloseable_`
47+
[tabs]
48+
====
49+
Java::
50+
+
51+
--
52+
[source,java,indent=0]
4853
----
4954
include::example$java/example/extensions/HttpServerResource.java[tags=user_guide]
5055
----
56+
--
57+
58+
Kotlin::
59+
+
60+
--
61+
[source,kotlin,indent=0]
62+
----
63+
include::example$kotlin/example/kotlin/extensions/HttpServerResource.kt[tags=user_guide]
64+
----
65+
--
66+
====
5167

5268
This resource can then be stored in the desired `ExtensionContext`. It may be stored at
5369
class or method level, if desired, but this may add unnecessary overhead for this type of
5470
resource. For this example it might be prudent to store it at root level and instantiate
5571
it lazily to ensure it's only created once per test run and reused across different test
5672
classes and methods.
5773

58-
[source,java,indent=0]
5974
.Lazily storing in root context with `_Store.computeIfAbsent_`
75+
[tabs]
76+
====
77+
Java::
78+
+
79+
--
80+
[source,java,indent=0]
6081
----
6182
include::example$java/example/extensions/HttpServerExtension.java[tags=user_guide]
6283
----
84+
--
85+
86+
Kotlin::
87+
+
88+
--
89+
[source,kotlin,indent=0]
90+
----
91+
include::example$kotlin/example/kotlin/extensions/HttpServerExtension.kt[tags=user_guide]
92+
----
93+
--
94+
====
6395

64-
[source,java,indent=0]
6596
.A test case using the `_HttpServerExtension_`
97+
[tabs]
98+
====
99+
Java::
100+
+
101+
--
102+
[source,java,indent=0]
66103
----
67104
include::example$java/example/HttpServerDemo.java[tags=user_guide]
68105
----
106+
--
107+
108+
Kotlin::
109+
+
110+
--
111+
[source,kotlin,indent=0]
112+
----
113+
include::example$kotlin/example/kotlin/HttpServerDemo.kt[tags=user_guide]
114+
----
115+
--
116+
====
69117

70118
[[migration]]
71119
[TIP]
72120
.Migration Note for Resource Cleanup
73-
====
121+
======
74122
The framework automatically closes resources stored in the `ExtensionContext.Store` that
75123
implement `AutoCloseable`. In versions prior to 5.13, only resources implementing
76124
`Store.CloseableResource` were automatically closed.
@@ -79,6 +127,11 @@ If you're developing an extension that needs to support both JUnit Jupiter 5.13+
79127
earlier versions and your extension stores resources that need to be cleaned up, you
80128
should implement both interfaces:
81129
130+
[tabs]
131+
====
132+
Java::
133+
+
134+
--
82135
[source,java,indent=0]
83136
----
84137
public class MyResource implements Store.CloseableResource, AutoCloseable {
@@ -88,7 +141,22 @@ public class MyResource implements Store.CloseableResource, AutoCloseable {
88141
}
89142
}
90143
----
144+
--
145+
146+
Kotlin::
147+
+
148+
--
149+
[source,kotlin,indent=0]
150+
----
151+
class MyResource : Store.CloseableResource, AutoCloseable {
152+
override fun close() {
153+
// Resource cleanup code
154+
}
155+
}
156+
----
157+
--
158+
====
91159

92160
This ensures that your resource will be properly closed regardless of which JUnit Jupiter
93161
version is being used.
94-
====
162+
======

documentation/modules/ROOT/pages/extensions/parameter-resolution.adoc

Lines changed: 68 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -60,38 +60,102 @@ registered for a test, a `ParameterResolutionException` will be thrown, with a
6060
message to indicate that competing resolvers have been discovered. See the following
6161
example:
6262

63-
[source,java,indent=0]
6463
.Conflicting parameter resolution due to multiple resolvers claiming support for integers
64+
[tabs]
65+
====
66+
Java::
67+
+
68+
--
69+
[source,java,indent=0]
6570
----
6671
include::example$java/example/extensions/ParameterResolverConflictDemo.java[tags=user_guide]
6772
----
73+
--
74+
75+
Kotlin::
76+
+
77+
--
78+
[source,kotlin,indent=0]
79+
----
80+
include::example$kotlin/example/kotlin/extensions/ParameterResolverConflictDemo.kt[tags=user_guide]
81+
----
82+
--
83+
====
6884

6985
If the conflicting `ParameterResolver` implementations are applied to different test
7086
methods as shown in the following example, no conflict occurs.
7187

72-
[source,java,indent=0]
7388
.Fine-grained registration to avoid conflict
89+
[tabs]
90+
====
91+
Java::
92+
+
93+
--
94+
[source,java,indent=0]
7495
----
7596
include::example$java/example/extensions/ParameterResolverNoConflictDemo.java[tags=user_guide]
7697
----
98+
--
99+
100+
Kotlin::
101+
+
102+
--
103+
[source,kotlin,indent=0]
104+
----
105+
include::example$kotlin/example/kotlin/extensions/ParameterResolverNoConflictDemo.kt[tags=user_guide]
106+
----
107+
--
108+
====
77109

78110
If the conflicting `ParameterResolver` implementations need to be applied to the same test
79111
method, you can implement a custom type or custom annotation as illustrated by
80112
`{CustomTypeParameterResolver}` and `{CustomAnnotationParameterResolver}`, respectively.
81113

82-
[source,java,indent=0]
83114
.Custom type to resolve duplicate types
115+
[tabs]
116+
====
117+
Java::
118+
+
119+
--
120+
[source,java,indent=0]
84121
----
85122
include::example$java/example/extensions/ParameterResolverCustomTypeDemo.java[tags=user_guide]
86123
----
124+
--
125+
126+
Kotlin::
127+
+
128+
--
129+
[source,kotlin,indent=0]
130+
----
131+
include::example$kotlin/example/kotlin/extensions/ParameterResolverCustomTypeDemo.kt[tags=user_guide]
132+
----
133+
--
134+
====
87135

88136
A custom annotation makes the duplicate type distinguishable from its counterpart:
89137

90-
[source,java,indent=0]
91138
.Custom annotation to resolve duplicate types
139+
[tabs]
140+
====
141+
Java::
142+
+
143+
--
144+
[source,java,indent=0]
92145
----
93146
include::example$java/example/extensions/ParameterResolverCustomAnnotationDemo.java[tags=user_guide]
94147
----
148+
--
149+
150+
Kotlin::
151+
+
152+
--
153+
[source,kotlin,indent=0]
154+
----
155+
include::example$kotlin/example/kotlin/extensions/ParameterResolverCustomAnnotationDemo.kt[tags=user_guide]
156+
----
157+
--
158+
====
95159

96160
JUnit includes some built-in parameter resolvers that can cause conflicts if a resolver
97161
attempts to claim their supported types. For example, `{TestInfo}` provides metadata about

0 commit comments

Comments
 (0)