skip to content

What conventions does the default `test` suite assume — its source set, task name, and how it relates to `check`?

level: juniorimportance: should knowfreq 30%

answer

  1. source set src/test/java
  2. default target task named test
  3. check depends on test
  4. build depends on check
  5. convention-over-configuration

basics

~10 s

The default test suite maps to the src/test/java (and resources) source set, produces the test task, and is wired into check so gradle check/build runs it.

solid answer

~40 s

When the java plugin registers the default `test` suite, it follows the standard conventions: the suite's source set is `test`, so sources live under `src/test/java`, `src/test/kotlin`, and `src/test/resources`. The suite has a single default target whose `Test` task is named `test`. That task is a dependency of the `check` lifecycle task, which `build` depends on — so the default suite runs as part of `gradle check` and `gradle build` without extra wiring. Configuring the suite (e.g. `useJUnitJupiter()`) configures exactly this source set / task / classpath triple. This convention-over-configuration mapping is what makes the basics ergonomic: you describe the framework and the rest of the topology is already in place.

code

bash · 4 lines
bash
# build runs check, which depends on the default suite's `test` task
./gradlew build
# equivalently, to run just the default suite:
./gradlew test

go deeper

for a junior

Recall the three conventions: src/test source set, test task, and that check/build run it.

for a middle

Explain that the suite DSL only needs the framework because the source-set/task/classpath topology is pre-wired by convention.

for a senior

Contrast convention defaults against what custom suites must declare, and note CI implications of check depending on test.

for a principal

Frame convention defaults as the baseline contract every module inherits, reducing per-module build divergence.

## Convention mapping of the default suite Applying the java plugin pre-wires the `test` suite with these conventions: | Aspect | Default value | |---|---| | Source set | `test` → `src/test/java`, `src/test/kotlin`, `src/test/resources` | | Classpath configs | `testImplementation`, `testCompileOnly`, `testRuntimeOnly`, etc. | | Default target's task | `test` (a `Test` task) | | Lifecycle hook | `check` depends on `test`; `build` depends on `check` | ## Why this matters Because the topology already exists, the suite DSL only needs you to express the *framework* and any *extra dependencies*. You don't create source sets or tasks for the default case — they're conventions. ```kotlin testing { suites { val test by getting(JvmTestSuite::class) { useJUnitJupiter() // dependencies { implementation("org.assertj:assertj-core:3.25.3") } } } } ``` Running `gradle build` compiles `main`, then `test`, then executes the `test` task as part of `check`. ## Relationship to suite dependencies The suite still uses the familiar `testImplementation`/`testRuntimeOnly` configurations under the hood for the default suite; the suite DSL adds a per-suite `dependencies {}` block as a tidier place to declare them. (Declaring extra dependencies on the suite is the adjacent topic; the *basics* are knowing the conventions are pre-wired.) ## Practical implication Since `test` is on `check`, CI that runs `./gradlew check` automatically runs the default suite — no separate test invocation needed.

  • Which lifecycle task runs the default suite automatically?
    `check` — it depends on the `test` task. Since `build` depends on `check`, `gradle build` (and CI's `gradle check`) runs the default suite.
  • Where do the default suite's test sources live?
    In the `test` source set: `src/test/java`, `src/test/kotlin`, and `src/test/resources`.

saying these in an interview costs you the question

  • Thinking you must manually wire `test` into `check`.
  • Saying the default suite's task is named `unitTest` or `check` rather than `test`.

context

resolving links…