skip to content

Explain the task input/output relationship of jacocoTestCoverageVerification: what it depends on, what makes it up-to-date, and why running it alone can still execute tests.

level: seniorimportance: nice to knowfreq 22%

answer

  1. type JacocoCoverageVerification
  2. inputs: exec + classes + sources + rules
  3. consumes test's .exec → test runs first
  4. rule edit invalidates up-to-date
  5. verification = assert, no artifact output

basics

~20 s

The verification task consumes the test execution data (.exec) and the compiled classes as inputs. Because it needs that data, it's wired to run after test, so invoking it triggers test first. It's up-to-date when inputs and rules are unchanged.

solid answer

~40 s

`jacocoTestCoverageVerification` is a `JacocoCoverageVerification` task. Its inputs are the JaCoCo `executionData` (the `.exec` files), the `classDirectories` (compiled classes), `sourceDirectories`, and the `violationRules` configuration; it has no meaningful file output (it's a verification task, so it's marked as not up-to-date when there's nothing to compare, but in practice Gradle still input-snapshots it). The plugin configures it to depend on / consume the output of the `test` task that produces the `.exec`, so running `./gradlew jacocoTestCoverageVerification` will run `test` first if tests aren't already current. It participates in incremental build: if classes, exec data, and rules are unchanged it can be `UP-TO-DATE` and skipped. Changing a threshold in the rules invalidates it and forces re-evaluation.

code

bash · 8 lines
bash
# Invoking verification pulls in test for the .exec data
./gradlew jacocoTestCoverageVerification

# Inspect why it ran / was skipped
./gradlew jacocoTestCoverageVerification --info

# Force re-evaluation ignoring up-to-date state
./gradlew --rerun-tasks jacocoTestCoverageVerification

go deeper

for a junior

Knowing it needs test data and runs after test is enough.

for a middle

Explain the .exec dependency and basic up-to-date skipping.

for a senior

Detail the input set including rules-as-input and the test-triggering behavior, and use it to reason about CI cost.

for a principal

Relate it to build-cache strategy across modules and incremental CI design.

## Task type and inputs The task is an instance of `JacocoCoverageVerification`. Like the report task, its key inputs are: - `executionData` — the `.exec` binary coverage data, normally from `build/jacoco/test.exec`. - `classDirectories` — compiled `.class` files to analyze. - `sourceDirectories` — sources (for resolving names). - `violationRules` — the rule configuration itself is an input; editing a threshold changes the task's input fingerprint. ## Dependency on test The `.exec` data is produced by the `test` task running with the JaCoCo agent attached. The jacoco plugin wires the verification (and report) tasks so they consume `test`'s execution data. Consequently, invoking the verification task directly causes Gradle to schedule `test` ahead of it when the test results aren't current. This is why 'I only ran the coverage check' can still spend minutes running the suite. ## Up-to-date behavior Gradle's incremental engine snapshots the task inputs. If the `.exec`, class files, sources, and rules are all unchanged since the last successful run, the task reports `UP-TO-DATE` and is skipped — fast. Touching a source file (which recompiles and reruns tests, regenerating `.exec`) or editing a `minimum` invalidates the snapshot and re-runs verification. ## Why it has no real output Verification tasks assert rather than produce artifacts. They either pass silently or throw. Because there's no output file to compare, Gradle relies on input changes for up-to-date checking; some Gradle versions therefore re-run verification tasks more eagerly, but the modern jacoco task does declare inputs that enable skipping. ## Practical implication for CI Because it depends on `test` and is input-cached, adding it to `check` is cheap on top of an already-running test suite. With the build cache, an unchanged module's verification can be pulled from cache rather than recomputed. ```bash # Runs test first if needed, then verifies thresholds ./gradlew jacocoTestCoverageVerification # Force a re-run regardless of up-to-date state ./gradlew --rerun-tasks jacocoTestCoverageVerification ```

  • Why might running only jacocoTestCoverageVerification still execute the whole test suite?
    Because its required input — the .exec execution data — is produced by the test task. The jacoco plugin wires the dependency, so Gradle runs test first whenever the test results aren't already up-to-date.
  • Is the violationRules configuration part of the task's up-to-date inputs?
    Yes. The rules are an input fingerprint, so changing a threshold (e.g. minimum 0.80 to 0.85) invalidates the task and forces it to re-evaluate even if code and .exec are unchanged.

saying these in an interview costs you the question

  • Saying it reads the HTML report instead of the .exec execution data.
  • Claiming it never re-runs once cached even after you change a threshold.
  • Assuming it produces an output file the way jacocoTestReport does.

context

resolving links…