4.5.5 Test Execution Output as Build Dependencies

Test reports are usually evidence from the test runner, not files in the normal build graph. This pattern is for the rarer case where a downstream build target must depend on execution-time evidence: coverage directories, logs, safety reports, or other proof that has to be packaged with a shipped artifact.¹ It deliberately turns one report-producing test run into a declared build action, so the report is a build output instead of a side effect.

The Missing Edge

The phase boundary from 2.2 Three Phases of a Build is the source of the surprise. A cc_test target is a build target whose default output is the test executable. bazel test builds that executable and then runs it under Bazel's test runner, but the files created while the test runs are not the same thing as the target's default build outputs.²

The difference is concrete. A pkg_tar that lists :foo_test as a source packages the compiled test executable, not the coverage reports and logs produced when that executable later runs as a test.³ Bazel also has a standard bazel coverage workflow, but the official coverage guide documents an important limitation: some coverage output files are not treated as normal graph inputs, which is why the coverage report combination action has special remote-execution caveats.⁴

The Test Encyclopedia provides another clue. Tests may write undeclared outputs under TEST_UNDECLARED_OUTPUTS_DIR, and Bazel zips those under bazel-testlogs. That is useful for test diagnostics, but it is not the same as declaring a file that another build target can consume through DefaultInfo.files.⁵ If another rule needs a report as an input, you need a target that declares that report.

Create A Report Target

The durable pattern is a sibling report target. Keep the ordinary test target for normal developer workflows, then add a custom rule target whose action runs the compiled test binary and declares the report files or report directory as outputs.⁶

def quality_cc_test(name, **kwargs):
    native.cc_test(
        name = name,
        **kwargs
    )

    _test_report(
        name = name + "_report",
        test_binary = ":" + name,
        testonly = True,
    )

The reporting rule is just a rule-authoring application of 4.2.2 Actions. During analysis it declares outputs such as coverage/, logs/, or a merged report file. During execution, its action launches the test binary and writes exactly those declared outputs. Returning them through DefaultInfo(files = ...) makes the report target buildable and consumable by ordinary targets.⁷

That changes the packaging edge:

pkg_tar(
    name = "foo_report",
    srcs = [":foo_test_report"],
    testonly = True,
)

Now foo_report depends on a build target that produces the report artifacts. The reports are no longer hidden behind a previous bazel test invocation or a path under bazel-testlogs. They are reachable artifacts in the requested build graph.⁸

Gate It Behind A Config

Do not make every bazel build run tests. A safe compromise is to activate the report path only under a quality configuration, such as bazel build --config=quality ..., while keeping default cc_test behavior unchanged for normal bazel test usage.⁹

That split matters for API design. The wrapper macro should make the report target discoverable and predictable, but not silently change the meaning of a normal test target. This is similar to the public-surface discipline from 4.5.3 Example Workspaces as Contract Tests and 4.5.4 Stardoc — API Documentation: users should be able to tell which target is the regular test and which target is the report-producing build artifact.

For larger systems, put the quality config in CI policy and release gating. H.7.2 Evidence Portfolio develops the monorepo-scale decision of which tests run before merge, after merge, or nightly. The narrower rule-authoring point here is: if a report must be a build dependency, model it as an output of a build rule.

Preserve The Test Contract Deliberately

Running a test binary as a build tool is not equivalent to bazel test. Direct execution of test binaries is allowed but not endorsed, because that invocation does not necessarily follow the full Bazel test environment contract.¹⁰ A report rule that needs test-like environment variables, writable directories, runfiles, or exit-code handling must provide that contract itself instead of assuming the test runner did it.

That is the main caveat. Using the test as a tool can be flaky.¹¹ The rule author has to decide which environment variables are stable, where the test may write, how report directories are cleaned, how failures are surfaced, and whether the action can run under the selected execution strategy. If the answer is "we just need coverage dashboards," the standard bazel coverage path is usually a better fit.¹²

This pattern is most defensible when a build artifact needs auditable evidence beside it: regulated automotive software, medical software, aerospace systems, or other release processes where reports are part of the delivered package.¹³ For ordinary developer feedback, keep tests as tests.