Migrate to Asciidoctor Tabs

framework-docs/modules/ROOT/pages/testing/testcontext-framework/application-events.adoc

@@ -28,8 +28,11 @@ https://assertj.github.io/doc/[AssertJ] to assert the types of application event
 published while invoking a method in a Spring-managed component:
 
 // Don't use "quotes" in the "subs" section because of the asterisks in /* ... */
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(/* ... */)
 	@RecordApplicationEvents // <1>
@@ -51,6 +54,7 @@ published while invoking a method in a Spring-managed component:
 		}
 	}
 ----
+======
 <1> Annotate the test class with `@RecordApplicationEvents`.
 <2> Inject the `ApplicationEvents` instance for the current test.
 <3> Use the `ApplicationEvents` API to count how many `OrderSubmitted` events were published.

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc

@@ -16,8 +16,11 @@ As an alternative to implementing the `ApplicationContextAware` interface, you c
 the application context for your test class through the `@Autowired` annotation on either
 a field or setter method, as the following example shows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig
 	class MyTest {
@@ -28,6 +31,7 @@ a field or setter method, as the following example shows:
 		// class body...
 	}
 ----
+======
 <1> Injecting the `ApplicationContext`.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -48,8 +52,11 @@ a field or setter method, as the following example shows:
 Similarly, if your test is configured to load a `WebApplicationContext`, you can inject
 the web application context into your test, as follows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitWebConfig // <1>
 	class MyWebAppTest {
@@ -60,6 +67,7 @@ the web application context into your test, as follows:
 		// class body...
 	}
 ----
+======
 <1> Configuring the `WebApplicationContext`.
 <2> Injecting the `WebApplicationContext`.
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc

@@ -38,8 +38,11 @@ ensure that each subclass gets its own `ApplicationContext` with the correct dyn
 properties.
 ====
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(/* ... */)
 	@Testcontainers
@@ -59,8 +62,10 @@ properties.
 
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(/* ... */)
 	@Testcontainers
@@ -85,6 +90,7 @@ properties.
 
 	}
 ----
+======
 
 [[precedence]]
 == Precedence

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc

@@ -59,8 +59,11 @@ Consider two examples with XML configuration and `@Configuration` classes:
 	</beans>
 ----
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from "classpath:/app-config.xml"
@@ -77,8 +80,10 @@ Consider two examples with XML configuration and `@Configuration` classes:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	// ApplicationContext will be loaded from "classpath:/app-config.xml"
@@ -95,6 +100,7 @@ Consider two examples with XML configuration and `@Configuration` classes:
 		}
 	}
 ----
+======
 
 When `TransferServiceTest` is run, its `ApplicationContext` is loaded from the
 `app-config.xml` configuration file in the root of the classpath. If you inspect
@@ -118,8 +124,11 @@ but define an in-memory data source as a default when neither of these is active
 The following code listings demonstrate how to implement the same configuration and
 integration test with `@Configuration` classes instead of XML:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Configuration
 	@Profile("dev")
@@ -135,8 +144,10 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Configuration
 	@Profile("dev")
@@ -152,9 +163,13 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+======
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Configuration
 	@Profile("production")
@@ -167,8 +182,10 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Configuration
 	@Profile("production")
@@ -181,9 +198,13 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+======
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Configuration
 	@Profile("default")
@@ -198,8 +219,10 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Configuration
 	@Profile("default")
@@ -214,9 +237,13 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+======
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Configuration
 	public class TransferServiceConfig {
@@ -239,8 +266,10 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Configuration
 	class TransferServiceConfig {
@@ -264,9 +293,13 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+======
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig({
 			TransferServiceConfig.class,
@@ -285,8 +318,10 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(
 			TransferServiceConfig::class,
@@ -305,6 +340,7 @@ integration test with `@Configuration` classes instead of XML:
 		}
 	}
 ----
+======
 
 In this variation, we have split the XML configuration into four independent
 `@Configuration` classes:
@@ -333,8 +369,11 @@ has been moved to an abstract superclass, `AbstractIntegrationTest`:
 NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing
 classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig({
 			TransferServiceConfig.class,
@@ -346,8 +385,9 @@ classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(
 			TransferServiceConfig::class,
@@ -358,9 +398,13 @@ classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext
 	abstract class AbstractIntegrationTest {
 	}
 ----
+======
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// "dev" profile inherited from superclass
 	class TransferServiceTest extends AbstractIntegrationTest {
@@ -374,8 +418,10 @@ classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// "dev" profile inherited from superclass
 	class TransferServiceTest : AbstractIntegrationTest() {
@@ -389,12 +435,16 @@ classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext
 		}
 	}
 ----
+======
 
 `@ActiveProfiles` also supports an `inheritProfiles` attribute that can be used to
 disable the inheritance of active profiles, as the following example shows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// "dev" profile overridden with "production"
 	@ActiveProfiles(profiles = "production", inheritProfiles = false)
@@ -403,8 +453,9 @@ disable the inheritance of active profiles, as the following example shows:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// "dev" profile overridden with "production"
 	@ActiveProfiles("production", inheritProfiles = false)
@@ -412,6 +463,7 @@ disable the inheritance of active profiles, as the following example shows:
 		// test body
 	}
 ----
+======
 
 [[testcontext-ctx-management-env-profiles-ActiveProfilesResolver]]
 Furthermore, it is sometimes necessary to resolve active profiles for tests
@@ -430,8 +482,11 @@ attribute of `@ActiveProfiles`. For further information, see the corresponding
 The following example demonstrates how to implement and register a custom
 `OperatingSystemActiveProfilesResolver`:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// "dev" profile overridden programmatically via a custom resolver
 	@ActiveProfiles(
@@ -442,8 +497,9 @@ The following example demonstrates how to implement and register a custom
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// "dev" profile overridden programmatically via a custom resolver
 	@ActiveProfiles(
@@ -453,9 +509,13 @@ The following example demonstrates how to implement and register a custom
 		// test body
 	}
 ----
+======
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	public class OperatingSystemActiveProfilesResolver implements ActiveProfilesResolver {
 
@@ -467,8 +527,10 @@ The following example demonstrates how to implement and register a custom
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	class OperatingSystemActiveProfilesResolver : ActiveProfilesResolver {
 
@@ -479,4 +541,5 @@ The following example demonstrates how to implement and register a custom
 		}
 	}
 ----
+======
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc

@@ -14,8 +14,11 @@ TestContext Framework is enabled automatically if Groovy is on the classpath.
 
 The following example shows how to specify Groovy configuration files:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from "/AppConfig.groovy" and
@@ -25,6 +28,7 @@ The following example shows how to specify Groovy configuration files:
 		// class body...
 	}
 ----
+======
 <1> Specifying the location of Groovy configuration files.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -49,8 +53,11 @@ detect a default location based on the name of the test class. If your class is
 `"classpath:com/example/MyTestContext.groovy"`. The following example shows how to use
 the default:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from
@@ -60,6 +67,7 @@ the default:
 		// class body...
 	}
 ----
+======
 <1> Loading configuration from the default location.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -87,8 +95,11 @@ configured resource location ends with `.xml`, it is loaded by using an
 
 The following listing shows how to combine both in an integration test:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from
@@ -98,8 +109,10 @@ The following listing shows how to combine both in an integration test:
 		// class body...
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	// ApplicationContext will be loaded from
@@ -109,5 +122,6 @@ The following listing shows how to combine both in an integration test:
 		// class body...
 	}
 ----
+======
 =====
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/hierarchies.adoc

@@ -35,8 +35,11 @@ one for the root `WebApplicationContext` (loaded by using the `TestAppConfig`
 that is autowired into the test instance is the one for the child context (that is, the
 lowest context in the hierarchy). The following listing shows this configuration scenario:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	@WebAppConfiguration
@@ -53,8 +56,9 @@ lowest context in the hierarchy). The following listing shows this configuration
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	@WebAppConfiguration
@@ -69,6 +73,7 @@ lowest context in the hierarchy). The following listing shows this configuration
 		// ...
 	}
 ----
+======
 --
 
 **Class hierarchy with implicit parent context**
@@ -86,8 +91,11 @@ based on the configuration in `AbstractWebTests` is set as the parent context fo
 the contexts loaded for the concrete subclasses. The following listing shows this
 configuration scenario:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	@WebAppConfiguration
@@ -100,8 +108,10 @@ configuration scenario:
 	@ContextHierarchy(@ContextConfiguration("/spring/rest-ws-config.xml"))
 	public class RestWebServiceTests extends AbstractWebTests {}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	@WebAppConfiguration
@@ -115,6 +125,7 @@ configuration scenario:
 	class RestWebServiceTests : AbstractWebTests()
 
 ----
+======
 --
 
 **Class hierarchy with merged context hierarchy configuration**
@@ -131,8 +142,11 @@ application context loaded from `/app-config.xml` is set as the parent context f
 contexts loaded from `/user-config.xml` and `{"/user-config.xml", "/order-config.xml"}`.
 The following listing shows this configuration scenario:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	@ContextHierarchy({
@@ -147,8 +161,9 @@ The following listing shows this configuration scenario:
 	class ExtendedTests extends BaseTests {}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	@ContextHierarchy(
@@ -161,6 +176,7 @@ The following listing shows this configuration scenario:
 	)
 	class ExtendedTests : BaseTests() {}
 ----
+======
 --
 
 **Class hierarchy with overridden context hierarchy configuration**
@@ -172,8 +188,11 @@ application context for `ExtendedTests` is loaded only from `/test-user-config.x
 has its parent set to the context loaded from `/app-config.xml`. The following listing
 shows this configuration scenario:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	@ContextHierarchy({
@@ -190,8 +209,10 @@ shows this configuration scenario:
 	))
 	class ExtendedTests extends BaseTests {}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	@ContextHierarchy(
@@ -207,6 +228,7 @@ shows this configuration scenario:
 			))
 	class ExtendedTests : BaseTests() {}
 ----
+======
 
 .Dirtying a context within a context hierarchy
 NOTE: If you use `@DirtiesContext` in a test whose context is configured as part of a

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc

@@ -26,8 +26,11 @@ Beans defined in `extended-config.xml` can, therefore, override (that is, replac
 defined in `base-config.xml`. The following example shows how one class can extend
 another and use both its own configuration file and the superclass's configuration file:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from "/base-config.xml"
@@ -44,6 +47,7 @@ another and use both its own configuration file and the superclass's configurati
 		// class body...
 	}
 ----
+======
 <1> Configuration file defined in the superclass.
 <2> Configuration file defined in the subclass.
 
@@ -75,8 +79,11 @@ order. Beans defined in `ExtendedConfig` can, therefore, override (that is, repl
 those defined in `BaseConfig`. The following example shows how one class can extend
 another and use both its own configuration class and the superclass's configuration class:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// ApplicationContext will be loaded from BaseConfig
 	@SpringJUnitConfig(BaseConfig.class) // <1>
@@ -90,6 +97,7 @@ another and use both its own configuration class and the superclass's configurat
 		// class body...
 	}
 ----
+======
 <1> Configuration class defined in the superclass.
 <2> Configuration class defined in the subclass.
 
@@ -119,8 +127,11 @@ implement Spring's `Ordered` interface or are annotated with Spring's `@Order` a
 or the standard `@Priority` annotation. The following example shows how one class can
 extend another and use both its own initializer and the superclass's initializer:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// ApplicationContext will be initialized by BaseInitializer
 	@SpringJUnitConfig(initializers = BaseInitializer.class) // <1>
@@ -135,6 +146,7 @@ extend another and use both its own initializer and the superclass's initializer
 		// class body...
 	}
 ----
+======
 <1> Initializer defined in the superclass.
 <2> Initializer defined in the subclass.
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/initializers.adoc

@@ -13,8 +13,11 @@ order in which the initializers are invoked depends on whether they implement Sp
 `Ordered` interface or are annotated with Spring's `@Order` annotation or the standard
 `@Priority` annotation. The following example shows how to use initializers:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from TestConfig
@@ -26,6 +29,7 @@ order in which the initializers are invoked depends on whether they implement Sp
 		// class body...
 	}
 ----
+======
 <1> Specifying configuration by using a configuration class and an initializer.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -50,8 +54,11 @@ component classes in `@ContextConfiguration` entirely and instead declare only
 in the context -- for example, by programmatically loading bean definitions from XML
 files or configuration classes. The following example shows how to do so:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be initialized by EntireAppInitializer
@@ -61,6 +68,7 @@ files or configuration classes. The following example shows how to do so:
 		// class body...
 	}
 ----
+======
 <1> Specifying configuration by using only an initializer.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/javaconfig.adoc

@@ -6,8 +6,11 @@ xref:core/beans/java.adoc[Java-based container configuration]), you can annotate
 class with `@ContextConfiguration` and configure the `classes` attribute with an array
 that contains references to component classes. The following example shows how to do so:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from AppConfig and TestConfig
@@ -16,6 +19,7 @@ that contains references to component classes. The following example shows how t
 		// class body...
 	}
 ----
+======
 <1> Specifying component classes.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -64,8 +68,11 @@ example, the `OrderServiceTest` class declares a `static` nested configuration c
 named `Config` that is automatically used to load the `ApplicationContext` for the test
 class:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig <1>
 	// ApplicationContext will be loaded from the static nested Config class
@@ -93,6 +100,7 @@ class:
 
 	}
 ----
+======
 <1> Loading configuration information from the nested `Config` class.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc

@@ -40,8 +40,11 @@ loaded by using the specified resource protocol. Resource location wildcards (su
 
 The following example uses a test properties file:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ContextConfiguration
 	@TestPropertySource("/test.properties") // <1>
@@ -49,6 +52,7 @@ The following example uses a test properties file:
 		// class body...
 	}
 ----
+======
 <1> Specifying a properties file with an absolute path.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -77,8 +81,11 @@ a Java properties file:
 
 The following example sets two inlined properties:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ContextConfiguration
 	@TestPropertySource(properties = {"timezone = GMT", "port: 4242"}) // <1>
@@ -86,6 +93,7 @@ The following example sets two inlined properties:
 		// class body...
 	}
 ----
+======
 <1> Setting two properties by using two variations of the key-value syntax.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -147,8 +155,11 @@ entries for the `timezone` and `port` properties those are overridden by the inl
 properties declared by using the `properties` attribute. The following example shows how
 to specify properties both in a file and inline:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ContextConfiguration
 	@TestPropertySource(
@@ -160,8 +171,9 @@ to specify properties both in a file and inline:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ContextConfiguration
 	@TestPropertySource("/test.properties",
@@ -171,6 +183,7 @@ to specify properties both in a file and inline:
 		// class body...
 	}
 ----
+======
 
 [[inheriting-and-overriding-test-property-sources]]
 == Inheriting and Overriding Test Property Sources
@@ -199,8 +212,11 @@ for `ExtendedTest` is loaded by using the `base.properties` and `extended.proper
 files as test property source locations. The following example shows how to define
 properties in both a subclass and its superclass by using `properties` files:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@TestPropertySource("base.properties")
 	@ContextConfiguration
@@ -214,8 +230,10 @@ properties in both a subclass and its superclass by using `properties` files:
 		// ...
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@TestPropertySource("base.properties")
 	@ContextConfiguration
@@ -229,14 +247,18 @@ properties in both a subclass and its superclass by using `properties` files:
 		// ...
 	}
 ----
+======
 
 In the next example, the `ApplicationContext` for `BaseTest` is loaded by using only the
 inlined `key1` property. In contrast, the `ApplicationContext` for `ExtendedTest` is
 loaded by using the inlined `key1` and `key2` properties. The following example shows how
 to define properties in both a subclass and its superclass by using inline properties:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@TestPropertySource(properties = "key1 = value1")
 	@ContextConfiguration
@@ -250,8 +272,10 @@ to define properties in both a subclass and its superclass by using inline prope
 		// ...
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@TestPropertySource(properties = ["key1 = value1"])
 	@ContextConfiguration
@@ -265,4 +289,5 @@ to define properties in both a subclass and its superclass by using inline prope
 		// ...
 	}
 ----
+======
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web-mocks.adoc

@@ -18,9 +18,11 @@ mocks can be autowired into your test instance. Note that the `WebApplicationCon
 `MockServletContext` are both cached across the test suite, whereas the other mocks are
 managed per test method by the `ServletTestExecutionListener`.
 
-.Injecting mocks
+[tabs]
+======
+Injecting mocks::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitWebConfig
 	class WacTests {
@@ -47,8 +49,9 @@ managed per test method by the `ServletTestExecutionListener`.
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitWebConfig
 	class WacTests {
@@ -74,4 +77,5 @@ managed per test method by the `ServletTestExecutionListener`.
 		//...
 	}
 ----
+======
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web.adoc

@@ -29,9 +29,11 @@ The remaining examples in this section show some of the various configuration op
 loading a `WebApplicationContext`. The following example shows the TestContext
 framework's support for convention over configuration:
 
-.Conventions
+[tabs]
+======
+Conventions::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 
@@ -45,8 +47,10 @@ framework's support for convention over configuration:
 		//...
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 
@@ -60,6 +64,7 @@ framework's support for convention over configuration:
 		//...
 	}
 ----
+======
 
 If you annotate a test class with `@WebAppConfiguration` without specifying a resource
 base path, the resource path effectively defaults to `file:src/main/webapp`. Similarly,
@@ -71,9 +76,11 @@ as the `WacTests` class or static nested `@Configuration` classes).
 The following example shows how to explicitly declare a resource base path with
 `@WebAppConfiguration` and an XML resource location with `@ContextConfiguration`:
 
-.Default resource semantics
+[tabs]
+======
+Default resource semantics::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 
@@ -86,8 +93,10 @@ The following example shows how to explicitly declare a resource base path with
 		//...
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 
@@ -100,6 +109,7 @@ The following example shows how to explicitly declare a resource base path with
 		//...
 	}
 ----
+======
 
 The important thing to note here is the different semantics for paths with these two
 annotations. By default, `@WebAppConfiguration` resource paths are file system based,
@@ -108,9 +118,11 @@ whereas `@ContextConfiguration` resource locations are classpath based.
 The following example shows that we can override the default resource semantics for both
 annotations by specifying a Spring resource prefix:
 
-.Explicit resource semantics
+[tabs]
+======
+Explicit resource semantics::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 
@@ -123,8 +135,10 @@ annotations by specifying a Spring resource prefix:
 		//...
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 
@@ -137,6 +151,7 @@ annotations by specifying a Spring resource prefix:
 		//...
 	}
 ----
+======
 
 Contrast the comments in this example with the previous example.
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/xml.adoc

@@ -10,8 +10,11 @@ is treated as an absolute classpath location (for example, `/org/example/config.
 path that represents a resource URL (i.e., a path prefixed with `classpath:`, `file:`,
 `http:`, etc.) is used _as is_.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from "/app-config.xml" and
@@ -21,6 +24,7 @@ path that represents a resource URL (i.e., a path prefixed with `classpath:`, `f
 		// class body...
 	}
 ----
+======
 <1> Setting the locations attribute to a list of XML files.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -43,8 +47,11 @@ attributes in `@ContextConfiguration`, you can omit the declaration of the `loca
 attribute name and declare the resource locations by using the shorthand format
 demonstrated in the following example:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	@ContextConfiguration({"/app-config.xml", "/test-config.xml"}) <1>
@@ -52,6 +59,7 @@ demonstrated in the following example:
 		// class body...
 	}
 ----
+======
 <1> Specifying XML files without using the `locations` attribute.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
@@ -74,8 +82,11 @@ class. If your class is named `com.example.MyTest`, `GenericXmlContextLoader` lo
 application context from `"classpath:com/example/MyTest-context.xml"`. The following
 example shows how to do so:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// ApplicationContext will be loaded from
@@ -85,6 +96,7 @@ example shows how to do so:
 		// class body...
 	}
 ----
+======
 <1> Loading configuration from the default location.
 
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]

framework-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc

@@ -46,8 +46,11 @@ to run the populator against a `javax.sql.DataSource`. The following example
 specifies SQL scripts for a test schema and test data, sets the statement separator to
 `@@`, and run the scripts against a `DataSource`:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Test
 	void databaseTest() {
@@ -60,8 +63,10 @@ specifies SQL scripts for a test schema and test data, sets the statement separa
 		// run code that uses the test schema and data
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Test
 	fun databaseTest() {
@@ -74,6 +79,7 @@ specifies SQL scripts for a test schema and test data, sets the statement separa
 		// run code that uses the test schema and data
 	}
 ----
+======
 
 Note that `ResourceDatabasePopulator` internally delegates to `ScriptUtils` for parsing
 and running SQL scripts. Similarly, the `executeSqlScript(..)` methods in
@@ -110,8 +116,11 @@ the specified resource protocol.
 The following example shows how to use `@Sql` at the class level and at the method level
 within a JUnit Jupiter based integration test class:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig
 	@Sql("/test-schema.sql")
@@ -130,8 +139,9 @@ within a JUnit Jupiter based integration test class:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig
 	@Sql("/test-schema.sql")
@@ -149,6 +159,7 @@ within a JUnit Jupiter based integration test class:
 		}
 	}
 ----
+======
 
 [[testcontext-executing-sql-declaratively-script-detection]]
 === Default Script Detection
@@ -175,8 +186,11 @@ Java 8, you can use `@Sql` as a repeatable annotation. Otherwise, you can use th
 
 The following example shows how to use `@Sql` as a repeatable annotation with Java 8:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Test
 	@Sql(scripts = "/test-schema.sql", config = @SqlConfig(commentPrefix = "`"))
@@ -185,11 +199,14 @@ The following example shows how to use `@Sql` as a repeatable annotation with Ja
 		// run code that uses the test schema and test data
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// Repeatable annotations with non-SOURCE retention are not yet supported by Kotlin
 ----
+======
 
 In the scenario presented in the preceding example, the `test-schema.sql` script uses a
 different syntax for single-line comments.
@@ -199,8 +216,11 @@ declarations are grouped together within `@SqlGroup`. With Java 8 and above, the
 `@SqlGroup` is optional, but you may need to use `@SqlGroup` for compatibility with
 other JVM languages such as Kotlin.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Test
 	@SqlGroup({
@@ -211,8 +231,10 @@ other JVM languages such as Kotlin.
 		// run code that uses the test schema and test data
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Test
 	@SqlGroup(
@@ -222,6 +244,7 @@ other JVM languages such as Kotlin.
 		// Run code that uses the test schema and test data
 	}
 ----
+======
 
 [[testcontext-executing-sql-declaratively-script-execution-phases]]
 === Script Execution Phases
@@ -231,8 +254,11 @@ you need to run a particular set of scripts after the test method (for example,
 up database state), you can use the `executionPhase` attribute in `@Sql`, as the
 following example shows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@Test
 	@Sql(
@@ -249,8 +275,10 @@ following example shows:
 		// to the database outside of the test's transaction
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@Test
 	@SqlGroup(
@@ -264,6 +292,7 @@ following example shows:
 		// to the database outside of the test's transaction
 	}
 ----
+======
 
 Note that `ISOLATED` and `AFTER_TEST_METHOD` are statically imported from
 `Sql.TransactionMode` and `Sql.ExecutionPhase`, respectively.
@@ -319,8 +348,11 @@ reference manual, the javadoc for
 provide detailed information, and the following example shows a typical testing scenario
 that uses JUnit Jupiter and transactional tests with `@Sql`:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(TestDatabaseConfig.class)
 	@Transactional
@@ -351,8 +383,10 @@ that uses JUnit Jupiter and transactional tests with `@Sql`:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(TestDatabaseConfig::class)
 	@Transactional
@@ -378,6 +412,7 @@ that uses JUnit Jupiter and transactional tests with `@Sql`:
 		}
 	}
 ----
+======
 
 Note that there is no need to clean up the database after the `usersTest()` method is
 run, since any changes made to the database (either within the test method or within the

framework-docs/modules/ROOT/pages/testing/testcontext-framework/fixture-di.adoc

@@ -54,8 +54,11 @@ example.
 The first code listing shows a JUnit Jupiter based implementation of the test class that
 uses `@Autowired` for field injection:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// specifies the Spring configuration to load for this test fixture
@@ -74,8 +77,9 @@ uses `@Autowired` for field injection:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	// specifies the Spring configuration to load for this test fixture
@@ -93,12 +97,16 @@ uses `@Autowired` for field injection:
 		}
 	}
 ----
+======
 
 Alternatively, you can configure the class to use `@Autowired` for setter injection, as
 follows:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ExtendWith(SpringExtension.class)
 	// specifies the Spring configuration to load for this test fixture
@@ -121,8 +129,9 @@ follows:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ExtendWith(SpringExtension::class)
 	// specifies the Spring configuration to load for this test fixture
@@ -144,6 +153,7 @@ follows:
 		}
 	}
 ----
+======
 
 The preceding code listings use the same XML context file referenced by the
 `@ContextConfiguration` annotation (that is, `repository-config.xml`). The following
@@ -178,8 +188,11 @@ such a case, you can override the setter method and use the `@Qualifier` annotat
 indicate a specific target bean, as follows (but make sure to delegate to the overridden
 method in the superclass as well):
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// ...
 
@@ -192,8 +205,9 @@ method in the superclass as well):
 	// ...
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// ...
 
@@ -204,6 +218,7 @@ method in the superclass as well):
 
 	// ...
 ----
+======
 
 The specified qualifier value indicates the specific `DataSource` bean to inject,
 narrowing the set of type matches to a specific bean. Its value is matched against

framework-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc

@@ -20,8 +20,11 @@ xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules
 The following code listing shows the minimal requirements for configuring a test class to
 run with the custom Spring `Runner`:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@RunWith(SpringRunner.class)
 	@TestExecutionListeners({})
@@ -34,8 +37,9 @@ run with the custom Spring `Runner`:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@RunWith(SpringRunner::class)
 	@TestExecutionListeners
@@ -47,6 +51,7 @@ run with the custom Spring `Runner`:
 		}
 	}
 ----
+======
 
 In the preceding example, `@TestExecutionListeners` is configured with an empty list, to
 disable the default listeners, which otherwise would require an `ApplicationContext` to
@@ -74,8 +79,11 @@ To support the full functionality of the TestContext framework, you must combine
 `SpringClassRule` with a `SpringMethodRule`. The following example shows the proper way
 to declare these rules in an integration test:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// Optionally specify a non-Spring Runner via @RunWith(...)
 	@ContextConfiguration
@@ -94,8 +102,9 @@ to declare these rules in an integration test:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// Optionally specify a non-Spring Runner via @RunWith(...)
 	@ContextConfiguration
@@ -115,6 +124,7 @@ to declare these rules in an integration test:
 		}
 	}
 ----
+======
 
 [[testcontext-support-classes-junit4]]
 == JUnit 4 Support Classes
@@ -179,8 +189,11 @@ TestNG:
 The following code listing shows how to configure a test class to use the
 `SpringExtension` in conjunction with `@ContextConfiguration`:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// Instructs JUnit Jupiter to extend the test with Spring support.
 	@ExtendWith(SpringExtension.class)
@@ -195,8 +208,9 @@ The following code listing shows how to configure a test class to use the
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// Instructs JUnit Jupiter to extend the test with Spring support.
 	@ExtendWith(SpringExtension::class)
@@ -210,6 +224,7 @@ The following code listing shows how to configure a test class to use the
 		}
 	}
 ----
+======
 
 Since you can also use annotations in JUnit 5 as meta-annotations, Spring provides the
 `@SpringJUnitConfig` and `@SpringJUnitWebConfig` composed annotations to simplify the
@@ -218,8 +233,11 @@ configuration of the test `ApplicationContext` and JUnit Jupiter.
 The following example uses `@SpringJUnitConfig` to reduce the amount of configuration
 used in the previous example:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// Instructs Spring to register the SpringExtension with JUnit
 	// Jupiter and load an ApplicationContext from TestConfig.class
@@ -233,8 +251,9 @@ used in the previous example:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// Instructs Spring to register the SpringExtension with JUnit
 	// Jupiter and load an ApplicationContext from TestConfig.class
@@ -247,12 +266,16 @@ used in the previous example:
 		}
 	}
 ----
+======
 
 Similarly, the following example uses `@SpringJUnitWebConfig` to create a
 `WebApplicationContext` for use with JUnit Jupiter:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// Instructs Spring to register the SpringExtension with JUnit
 	// Jupiter and load a WebApplicationContext from TestWebConfig.class
@@ -266,8 +289,9 @@ Similarly, the following example uses `@SpringJUnitWebConfig` to create a
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// Instructs Spring to register the SpringExtension with JUnit
 	// Jupiter and load a WebApplicationContext from TestWebConfig::class
@@ -280,6 +304,7 @@ Similarly, the following example uses `@SpringJUnitWebConfig` to create a
 		}
 	}
 ----
+======
 
 See the documentation for `@SpringJUnitConfig` and `@SpringJUnitWebConfig` in
 xref:testing/annotations/integration-junit-jupiter.adoc[Spring JUnit Jupiter Testing Annotations] for further details.
@@ -345,8 +370,11 @@ In the following example, Spring injects the `OrderService` bean from the
 `ApplicationContext` loaded from `TestConfig.class` into the
 `OrderServiceIntegrationTests` constructor.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(TestConfig.class)
 	class OrderServiceIntegrationTests {
@@ -362,8 +390,9 @@ In the following example, Spring injects the `OrderService` bean from the
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(TestConfig::class)
 	class OrderServiceIntegrationTests @Autowired constructor(private val orderService: OrderService){
@@ -371,6 +400,7 @@ In the following example, Spring injects the `OrderService` bean from the
 	}
 
 ----
+======
 
 Note that this feature lets test dependencies be `final` and therefore immutable.
 
@@ -378,8 +408,11 @@ If the `spring.test.constructor.autowire.mode` property is to `all` (see
 xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[`@TestConstructor`]), we can omit the declaration of
 `@Autowired` on the constructor in the previous example, resulting in the following.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(TestConfig.class)
 	class OrderServiceIntegrationTests {
@@ -394,14 +427,16 @@ xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-anno
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(TestConfig::class)
 	class OrderServiceIntegrationTests(val orderService:OrderService) {
 		// tests that use the injected OrderService
 	}
 ----
+======
 
 [[testcontext-junit-jupiter-di-method]]
 ==== Method Injection
@@ -414,8 +449,11 @@ parameter with the corresponding bean from the test's `ApplicationContext`.
 In the following example, Spring injects the `OrderService` from the `ApplicationContext`
 loaded from `TestConfig.class` into the `deleteOrder()` test method:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(TestConfig.class)
 	class OrderServiceIntegrationTests {
@@ -427,8 +465,9 @@ loaded from `TestConfig.class` into the `deleteOrder()` test method:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(TestConfig::class)
 	class OrderServiceIntegrationTests {
@@ -439,6 +478,7 @@ loaded from `TestConfig.class` into the `deleteOrder()` test method:
 		}
 	}
 ----
+======
 
 Due to the robustness of the `ParameterResolver` support in JUnit Jupiter, you can also
 have multiple dependencies injected into a single method, not only from Spring but also
@@ -447,8 +487,11 @@ from JUnit Jupiter itself or other third-party extensions.
 The following example shows how to have both Spring and JUnit Jupiter inject dependencies
 into the `placeOrderRepeatedly()` test method simultaneously.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(TestConfig.class)
 	class OrderServiceIntegrationTests {
@@ -463,8 +506,9 @@ into the `placeOrderRepeatedly()` test method simultaneously.
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(TestConfig::class)
 	class OrderServiceIntegrationTests {
@@ -477,6 +521,7 @@ into the `placeOrderRepeatedly()` test method simultaneously.
 		}
 	}
 ----
+======
 
 Note that the use of `@RepeatedTest` from JUnit Jupiter lets the test method gain access
 to the `RepetitionInfo`.
@@ -514,8 +559,11 @@ xref:testing/testcontext-framework/ctx-management/caching.adoc[Context Caching]
 xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-nestedtestconfiguration[supported annotations] to see
 which annotations can be inherited in `@Nested` test classes.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(TestConfig.class)
 	class GreetingServiceTests {
@@ -542,8 +590,9 @@ which annotations can be inherited in `@Nested` test classes.
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(TestConfig::class)
 	class GreetingServiceTests {
@@ -569,6 +618,7 @@ which annotations can be inherited in `@Nested` test classes.
 		}
 	}
 ----
+======
 
 [[testcontext-support-classes-testng]]
 == TestNG Support Classes

framework-docs/modules/ROOT/pages/testing/testcontext-framework/tel-config.adoc

@@ -37,8 +37,11 @@ If you extend a class that is annotated with `@TestExecutionListeners` and you n
 switch to using the default set of listeners, you can annotate your class with the
 following.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// Switch to default listeners
 	@TestExecutionListeners(
@@ -50,8 +53,9 @@ following.
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// Switch to default listeners
 	@TestExecutionListeners(
@@ -62,6 +66,7 @@ following.
 		// class body...
 	}
 ----
+======
 ====
 
 [[testcontext-tel-config-automatic-discovery]]
@@ -103,8 +108,11 @@ default listeners are not registered. In most common testing scenarios, this eff
 forces the developer to manually declare all default listeners in addition to any custom
 listeners. The following listing demonstrates this style of configuration:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ContextConfiguration
 	@TestExecutionListeners({
@@ -121,8 +129,9 @@ listeners. The following listing demonstrates this style of configuration:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ContextConfiguration
 	@TestExecutionListeners(
@@ -138,6 +147,7 @@ listeners. The following listing demonstrates this style of configuration:
 		// class body...
 	}
 ----
+======
 
 The challenge with this approach is that it requires that the developer know exactly
 which listeners are registered by default. Moreover, the set of default listeners can
@@ -165,8 +175,11 @@ configures its `order` value (for example, `500`) to be less than the order of t
 defaults in front of the `ServletTestExecutionListener`, and the previous example could
 be replaced with the following:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ContextConfiguration
 	@TestExecutionListeners(
@@ -177,8 +190,10 @@ be replaced with the following:
 		// class body...
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ContextConfiguration
 	@TestExecutionListeners(
@@ -189,4 +204,5 @@ be replaced with the following:
 		// class body...
 	}
 ----
+======
 

framework-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc

@@ -102,8 +102,11 @@ are preconfigured for transactional support at the class level.
 The following example demonstrates a common scenario for writing an integration test for
 a Hibernate-based `UserRepository`:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig(TestConfig.class)
 	@Transactional
@@ -145,8 +148,9 @@ a Hibernate-based `UserRepository`:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig(TestConfig::class)
 	@Transactional
@@ -187,6 +191,7 @@ a Hibernate-based `UserRepository`:
 		}
 	}
 ----
+======
 
 As explained in xref:testing/testcontext-framework/tx.adoc#testcontext-tx-rollback-and-commit-behavior[Transaction Rollback and Commit Behavior], there is no need to
 clean up the database after the `createUser()` method runs, since any changes made to the
@@ -214,8 +219,11 @@ The following example demonstrates some of the features of `TestTransaction`. Se
 javadoc for {api-spring-framework}/test/context/transaction/TestTransaction.html[`TestTransaction`]
 for further details.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@ContextConfiguration(classes = TestConfig.class)
 	public class ProgrammaticTransactionManagementTests extends
@@ -244,8 +252,10 @@ for further details.
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@ContextConfiguration(classes = [TestConfig::class])
 	class ProgrammaticTransactionManagementTests : AbstractTransactionalJUnit4SpringContextTests() {
@@ -273,6 +283,7 @@ for further details.
 		}
 	}
 ----
+======
 
 [[testcontext-tx-before-and-after-tx]]
 == Running Code Outside of a Transaction
@@ -318,8 +329,11 @@ information and configuration examples. xref:testing/testcontext-framework/execu
 declarative SQL script execution with default transaction rollback semantics. The
 following example shows the relevant annotations:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitConfig
 	@Transactional(transactionManager = "txMgr")
@@ -356,8 +370,9 @@ following example shows the relevant annotations:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitConfig
 	@Transactional(transactionManager = "txMgr")
@@ -393,6 +408,7 @@ following example shows the relevant annotations:
 
 	}
 ----
+======
 
 [[testcontext-tx-false-positives]]
 .Avoid false positives when testing ORM code
@@ -407,8 +423,11 @@ of work. In the following Hibernate-based example test case, one method demonstr
 false positive, and the other method correctly exposes the results of flushing the
 session:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// ...
 
@@ -434,8 +453,9 @@ session:
 	// ...
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// ...
 
@@ -460,11 +480,15 @@ session:
 
 	// ...
 ----
+======
 
 The following example shows matching methods for JPA:
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// ...
 
@@ -489,8 +513,10 @@ The following example shows matching methods for JPA:
 
 	// ...
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// ...
 
@@ -515,6 +541,7 @@ The following example shows matching methods for JPA:
 
 	// ...
 ----
+======
 =====
 
 [[testcontext-tx-orm-lifecycle-callbacks]]
@@ -539,8 +566,11 @@ The following example shows how to flush the `EntityManager` to ensure that
 a `@PostPersist` callback method has been registered for the `Person` entity used in the
 example.
 
+[tabs]
+======
+Java::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	// ...
 
@@ -565,8 +595,10 @@ example.
 
 	// ...
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	// ...
 
@@ -591,6 +623,7 @@ example.
 
 	// ...
 ----
+======
 
 See
 https://github.com/spring-projects/spring-framework/blob/main/spring-test/src/test/java/org/springframework/test/context/junit/jupiter/orm/JpaEntityListenerTests.java[JpaEntityListenerTests]

framework-docs/modules/ROOT/pages/testing/testcontext-framework/web-scoped-beans.adoc

@@ -47,9 +47,11 @@ the provided `MockHttpServletRequest`. When the `loginUser()` method is invoked
 set parameters). We can then perform assertions against the results based on the known
 inputs for the username and password. The following listing shows how to do so:
 
-.Request-scoped bean test
+[tabs]
+======
+Request-scoped bean test::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitWebConfig
 	class RequestScopedBeanTests {
@@ -67,8 +69,10 @@ inputs for the username and password. The following listing shows how to do so:
 		}
 	}
 ----
+
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitWebConfig
 	class RequestScopedBeanTests {
@@ -86,6 +90,7 @@ inputs for the username and password. The following listing shows how to do so:
 		}
 	}
 ----
+======
 
 The following code snippet is similar to the one we saw earlier for a request-scoped
 bean. However, this time, the `userService` bean has a dependency on a session-scoped
@@ -119,9 +124,11 @@ the user service has access to the session-scoped `userPreferences` for the curr
 `MockHttpSession`, and we can perform assertions against the results based on the
 configured theme. The following example shows how to do so:
 
-.Session-scoped bean test
+[tabs]
+======
+Session-scoped bean test::
++
 [source,java,indent=0,subs="verbatim,quotes",role="primary"]
-.Java
 ----
 	@SpringJUnitWebConfig
 	class SessionScopedBeanTests {
@@ -139,8 +146,9 @@ configured theme. The following example shows how to do so:
 	}
 ----
 
+Kotlin::
++
 [source,kotlin,indent=0,subs="verbatim,quotes",role="secondary"]
-.Kotlin
 ----
 	@SpringJUnitWebConfig
 	class SessionScopedBeanTests {
@@ -157,4 +165,5 @@ configured theme. The following example shows how to do so:
 		}
 	}
 ----
+======