A suite of tests and documentation for Spring Boot applications using a custom lifecycle to perform a training run with CDS or JVM Checkpoint Restore.
The training run of your application may require custom configuration, applied by default to your application or specifically to the training run, to prevent early database interaction for example. See related documentation for the most common dependencies:
-
Spring Data MongoDB, MongoDB Reactive, Redis
Note
|
Keep in mind that with CDS, a regular startup lifecycle will be performed during the optimized run, while checkpoint/restore will resume the lifecyle where it was stopped, without refreshing the configuration unless you use Spring Cloud refresh scope. |
There are two types of tests: unit tests and application tests.
Unit tests can be run using the test
task.
The appTest
task tests the application running on the JVM. The checkpointRestoreAppTest
(also available with the shorter cRAT
task name) task tests the application running on the JVM after a checkpoint/restore.
-
Docker to run external services such as database servers.
-
For CRaC, a CRaC enabled JDK such as the one provided by Bellsoft.
NoteIf using SDKMan then run sdk env install
.
-
Docker Desktop (Colima + QEMU does not support CRaC JDK in a reliable way)
-
Use
./run-dev-container.sh
before running Gradle commands.
Please read and follow the contributing guide.
./gradlew :<name of the group>:<name of the smoke test>:build
for example
./gradlew :framework:webmvc-tomcat:build
./gradlew :<name of the group>:<name of the smoke test>:<test task name>
Valid test task names are:
-
appTest
– tests the application running on the JVM -
checkpointRestoreAppTest
(also available with the shortercRAT
task name) – tests the application running on the JVM after a checkpoint/restore -
test
– executes the unit tests on the JVM
for example
./gradlew :framework:webmvc-tomcat:appTest
-
Create a new directory for your smoke test in the appropriate group
-
Include the directory in
settings.gradle
(new groups only) -
Run
./gradlew updateInfrastructure
to add the smoke test to the status page and CI pipeline
./gradlew :<name of the group>:<name of the smoke test>:build --include-build /path/to/your/project
Gradle will then substitute the dependency with your provided version.
Hint: You can use --include-build
multiple times.
First, install the snapshots into your local Maven cache.
You can now consume those snapshots using -PfromMavenLocal
which takes an
optional comma-separated list of group IDs:
./gradlew :framework:webmvc-tomcat:build -PfromMavenLocal=org.springframework
The preceding example will run the webmvc-tomcat
smoke test, resolving Spring Framework from your local Maven cache.
You can also just specify:
./gradlew :framework:webmvc-tomcat:build -PfromMavenLocal
Here all the dependencies will be resolved from your local Maven cache.
As the test doesn’t use the Spring Dependency Management Plugin, you can’t use the ext['…'] = '…'
method.
Instead, use Gradle dependency constraints.
Say, for example, you want to update the version of Spring Session JDBC to 3.0.0-SNAPSHOT
:
dependencies {
// ...
constraints {
implementation('org.springframework.session:spring-session-jdbc:3.0.0-SNAPSHOT')
}
}
This works for direct and transitive dependencies.
By default, org.springframework.boot.context.event.ApplicationReadyEvent
is used to trigger the checkpoint when the
application is ready. It is possible to specify another event to trigger the checkpoint with the following Gradle
configuration:
crSmokeTest {
checkpointEvent = "com.example.MyCustomEvent"
}