skip to content

What does `failFast` do on the Gradle `Test` task, and when would you use it?

level: middleimportance: should knowfreq 45%

answer

  1. stop on first failure
  2. default false
  3. --fail-fast CLI flag
  4. cancels other forked workers
  5. orthogonal to ignoreFailures

basics

~20 s

failFast = true makes the test task stop the whole test run as soon as the first test fails, instead of running every test. It shortens feedback time when you only care that something broke.

solid answer

~40 s

`failFast` is a boolean on the `Test` task (default `false`). When `true`, the test executor aborts the entire run after the first failing test, so remaining tests across all forked JVMs are cancelled. It trades complete failure coverage for faster feedback — useful in tight local edit/run loops or in early CI stages where you just want a quick red/green. It can also be toggled per-invocation with `--fail-fast` on the command line without editing the build. The downside is you only see one failure per run, which is bad when you want the full picture (e.g., before a release) — there you'd leave it `false`. It's orthogonal to `ignoreFailures`: `failFast` controls *when execution stops*, `ignoreFailures` controls *the build outcome*.

code

bash · 2 lines
bash
# Fast local feedback without editing the build file
./gradlew test --fail-fast

go deeper

for a junior

Know it stops the run on the first failure and defaults to false.

for a middle

Explain the trade-off (speed vs. complete failure list), the --fail-fast CLI flag, and that it differs from ignoreFailures.

for a senior

Discuss interaction with parallel forks, why it belongs on the CLI rather than the script, and where it's inappropriate (release runs, flaky suites).

for a principal

Position it within a CI tiering strategy: cheap fail-fast smoke gate early, full non-fail-fast run later; governance around not baking developer preferences into shared scripts.

## What `failFast` is `failFast` is a property on Gradle's `Test` task. Default is `false`, meaning Gradle runs **all** selected tests and reports every failure at the end. Setting it `true` tells the test executor to **stop scheduling further tests as soon as the first failure occurs** and tear down the test run. Because Gradle may run tests across several forked JVM processes in parallel (`maxParallelForks`), "fail fast" cancels the in-flight and pending work across those workers; tests already mid-execution may finish, but nothing new starts. ## CLI equivalent You don't have to bake it into the build. Any invocation can use: ```bash ./gradlew test --fail-fast ``` This is handy because fast-feedback is usually a *developer-local* preference, not something you want to force on the whole team via the build script. ## When to use it - **Inner dev loop:** you're iterating and want the build to stop the instant something breaks. - **Cheap early CI stage:** a quick smoke gate before the full, complete run. - **Huge suites where one failure means stop and fix.** ## When NOT to use it - **Release/nightly runs:** you want the *complete* list of failures, not just the first. - **Flaky suites:** the "first" failure is nondeterministic, so reports become inconsistent. ## Relationship to other properties `failFast` is independent of `ignoreFailures`. You could even combine `failFast = true` with `ignoreFailures = true`: stop at the first failure **and** keep the build green — an unusual combination, but it shows they answer different questions (when to stop vs. whether to fail the build). ```kotlin tasks.named<Test>("test") { failFast = true } ```

  • Does `failFast` interact with parallel forks?
    Yes. With `maxParallelForks > 1`, multiple worker JVMs run tests concurrently. On the first failure Gradle stops scheduling new tests across all workers; tests already executing may complete, but the run aborts shortly after.
  • Is `failFast` better set in the build script or on the command line?
    Usually the command line (`--fail-fast`), because fast feedback is a per-developer preference. Baking it into the script forces it on everyone, including release/nightly runs where you want all failures.

saying these in an interview costs you the question

  • Saying `failFast` makes the build pass or fail differently — it only changes when execution stops.
  • Claiming it guarantees the very first test that ran is the one reported; with parallel forks the 'first failure' is nondeterministic.
  • Recommending it globally for release pipelines where you want every failure.

context

resolving links…