-
Notifications
You must be signed in to change notification settings - Fork 53
Configuration
After applying the android-junit5 plugin to your project, you will get some additional configuration options for your new power in the form of the junitPlatform
block.
plugins {
id("com.android.application")
id("de.mannodermaus.android-junit5")
}
// ...
junitPlatform {
// Here it is!
}
You can pass a Configuration Parameter to the JUnit Platform using the configurationParameter(String, String)
method, or its pluralized companion, configurationParameters(Map<String, String>)
.
junitPlatform {
configurationParameter("junit.jupiter.testinstance.lifecycle.default", "per_class")
configurationParameters(mapOf(
"some.other.parameter" to "a.value",
"another.parameter" to "false"
))
}
Arguably the most common usage of configuring unit tests is related to filtering and selecting which tests to actually run. The android-junit5 plugin provides a powerful and expressive language to specify Tags & Engines on each build variant of your project.
To specify rules for all build variants at once, use the filters
clause:
junitPlatform {
filters {
// These patterns follow the same format as Gradle's include() API.
// For example, include all classes containing "Test" or "Tests" in their name,
// and exclude those containing "Ignored".
// More info in the Gradle docs:
// https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:include(java.lang.String%5B%5D)
includePattern("**/*Tests?*")
excludePattern("**/*Ignored*")
// Include all test classes tagged with @Tag("slow"), but exclude those annotated with @Tag("integration")
includeTags("slow")
excludeTags("integration")
// Include the "my-framework" TestEngine, but exclude the "other-framework" TestEngine
includeEngines("my-framework")
excludeEngines("other-framework")
}
}
On top of these global settings, you can specify specialized rules for each build variant, build type or flavor of your project. All clauses follow the xxxFilters
scheme, where xxx
is the name of a build type, product flavor or build variant. Have a look at the following example:
android {
// Assume two product flavors, and the default build types, "debug" and "release"
flavorDimensions("my-dimension")
productFlavors {
create("flavor1") {
dimension = "my-dimension"
}
create("flavor2") {
dimension = "my-dimension"
}
}
}
junitPlatform {
filters {
// Exclude all "slow" tests by default
excludeTags("slow")
}
filters("debug") {
// Include all test classes tagged with @Tag("slow"), but only for the flavor1Debug & flavor2Debug variants.
// This will overwrite the value inherited from the "filters" closure!
includeTags("slow")
}
filters("flavor1Release") {
// Exclude the "staging-engine" TestEngine, but only for the flavor1Release variant
excludeEngines("staging-engine")
}
}
The different specialization levels take priority over each other. From top to bottom, the following list shows the order of how the filters are applied to a build variant. Settings applied at a later point in the list overwrite contrarian settings applied before then:
- Default
- Build-type-specific (e.g. "debug")
- Flavor-specific (e.g. "flavor1")
- Variant-specific (e.g. "flavor1Debug")
If you use JUnit 5 to write instrumentation tests running on-device, the Gradle Plugin provides a couple of safeguards to assist you with the integration. Specifically, it will alert you about some inconsistencies in the integration process as outlined on this Wiki page.
junitPlatform {
instrumentationTests {
// Whether or not to validate configuration of instrumentation tests in this build
integrityCheckEnabled = true
}
}