skip to content

Failure Handling & Logging

4 roadmaps5 questions

ignoreFailures, failFast, and the testLogging block that decides both the build outcome and what appears in the console. Interviewers ask because Gradle's default output hides the stack trace people actually need.

on this pageshow

explore

questions

5

What does the `ignoreFailures` property on Gradle's `Test` task do, and why might you set it?

level: juniorimportance: must knowfreq 55%

answer

  1. default false
  2. build stays green on test failure
  3. reports still produced
  4. AbstractTestTask property
  5. pair with external gate

basics

~20 s

Setting test.ignoreFailures = true tells Gradle not to fail the build when tests fail. The test task still runs all tests and reports results, but a failing test no longer marks the build as failed.

solid answer

~40 s

By default the `Test` task throws and fails the build as soon as the test run finishes with any failures. Setting `ignoreFailures = true` keeps running and lets the task complete successfully even when tests fail, so downstream tasks (reports, aggregation) still run and the build exits 0. It's commonly used when you want to always publish the HTML/JUnit XML report regardless of outcome, or in matrix/aggregator builds that collect results elsewhere. The danger is that a green build can hide real test failures, so it should be paired with an external gate that inspects the reports. Note `ignoreFailures` controls the build *outcome*; it does not change which tests run or what's logged.

code

kotlin · 3 lines
kotlin
tasks.named<Test>("test") {
    ignoreFailures = true
}

go deeper

for a junior

Know that it makes the build pass even when tests fail, and that it's a boolean on the test task defaulting to false.

for a middle

Explain that reports still generate, downstream tasks run, and that you must add an external gate so failures aren't hidden.

for a senior

Discuss legitimate uses (report-always, aggregation builds) versus the anti-pattern of masking flakiness, and how to gate centrally.

for a principal

Frame a policy: ignoreFailures only behind an explicit verification gate, never as a way to hide debt; tie to CI governance and flaky-test quarantine strategy.

## What `ignoreFailures` is The `Test` task type in Gradle extends `AbstractTestTask`, which exposes a boolean property `ignoreFailures`. Its default is `false`. When `false` (default): after the test run completes, if **any** test failed, the task throws a `VerificationException` (historically a `GradleException`/`TestExecutionException`), the task is marked FAILED, and the build aborts with a non-zero exit code. Subsequent tasks that depend on `test` do **not** run. When `true`: the task executes every test the same way, collects the same results, writes the same reports — but at the end it does **not** throw. The task is marked as successful (or UP-TO-DATE on re-run), the build exits 0, and downstream tasks proceed. ## Why you'd set it - **Always produce reports/artifacts.** You want the JUnit XML (`build/test-results/test/`) and HTML report (`build/reports/tests/test/`) published to CI even when tests fail, and a hard build failure would skip the publishing task. - **Aggregation builds.** A separate gate (a CI step, a custom verification task, or the `test-report-aggregation` plugin) inspects results across modules and decides pass/fail centrally. - **Soft/experimental suites.** A flaky or in-progress suite that shouldn't block the pipeline yet. ## The risk A build that exits 0 with failing tests is dangerous: developers and CI will treat it as green. If you set `ignoreFailures`, you must add an explicit external check that reads the result files and fails the pipeline. Prefer fixing/quarantining flaky tests over globally ignoring failures. ```kotlin tasks.test { ignoreFailures = true // build stays green; gate elsewhere finalizedBy("checkTestResults") // a task that parses XML and fails on errors } ``` ## Scope `ignoreFailures` only affects the **build outcome**. It does not change which tests execute, the order, forking, or console logging — those are separate properties (`failFast`, `testLogging`, `forkEvery`, etc.).

  • If `ignoreFailures = true`, will a finalizer task that publishes reports still run?
    Yes. Because the test task completes successfully, any `finalizedBy` or dependent task runs normally. That is precisely a common reason to set it — though `finalizedBy` actually runs even on failure too, so the real win is keeping the overall build exit code 0.
  • How can you keep `ignoreFailures` and still fail CI on real failures?
    Add a downstream task that parses `build/test-results/**/*.xml` for `<failure>`/`<error>` elements and throws, or have CI inspect the JUnit XML. This decouples report generation from the pass/fail decision.

saying these in an interview costs you the question

  • Claiming `ignoreFailures` stops failing tests from running — it only changes the build outcome, not execution.
  • Treating it as a normal default for all projects; it can silently hide regressions.
  • Confusing it with `failFast`, which is about stopping early, not about the build outcome.

context

resolving links…

open as a page

How do you configure `testLogging` so the console shows passed, skipped, and failed test events with full stack traces?

level: middleimportance: must knowfreq 60%

basics

~10 s

Inside the test task use a testLogging { } block: set events("passed", "skipped", "failed") to print each event, and exceptionFormat = TestExceptionFormat.FULL to show complete stack traces instead of truncated ones.

open as a page

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

level: middleimportance: should knowfreq 45%

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.

open as a page

A teammate sets `ignoreFailures`, `failFast`, and `testLogging` thinking they all relate to handling failures. Explain how these three differ and how they compose.

level: seniorimportance: should knowfreq 35%

basics

~20 s

They answer different questions: failFast = when execution stops (first failure vs. run all); ignoreFailures = whether the build fails on test failures; testLogging = what prints to the console. They are orthogonal and can be combined.

open as a page

How would you make Gradle fail when a test task runs zero tests, and surface noisy stdout only when debugging?

level: seniorimportance: nice to knowfreq 22%

basics

~20 s

By default a Test task that matches zero tests still passes, which hides broken filters. You can use a beforeSuite/afterSuite listener counting executed tests, or TestFrameworkOptions failure-on-no-tests, and gate stdout behind the info log level's testLogging so it's quiet normally.

open as a page