CargoTestOptions
Extra knobs for Cargo.test.
interface in bldr/rust-tools
Extra knobs for Cargo.test.
Properties
allFeatures: boolean
property
Enable every feature the crate declares (--all-features).
binArgs: string[]
property
Extra arguments for the program cargo runs, placed after --.
Which program that is depends on the command: the test harness for a test
run, the lint driver for clippy, rustdoc for a docs build. Kept separate
from cargoArgs because the two are not interchangeable — cargo
rejects a harness flag it does not know, and the harness never sees a flag
left on cargo's side of the separator.
// Run only the tests whose name contains "parse", single-threaded.
c.test({ binArgs: ["parse", "--test-threads=1"] });bins: boolean
property
--bins — run every binary's unit tests.
cargoArgs: string[]
property
Extra arguments for cargo itself, placed before the -- separator.
This is where target selectors and cargo flags go: ["--lib", "--tests"],
["--no-fail-fast"], ["--locked"].
c.test({ lib: true, noFailFast: true });compileOnly: Record<string, string>
property
Target selectors that must compile but must not run, as the cargo
flag → the reason running it here would be wrong. For example
{ "--tests": "integration tests need a live daemon, not a build pod" }.
They are appended to the --no-run pass only, so the run keeps exactly
the selection CargoOptions.cargoArgs asks for. That is still a
real gate: the compile happens in the same pod, against a /target that
already holds the dependency graph, and a failure fails the build with the
compiler's output as the failing task's log.
This exists because "we cannot run it here" quietly became "we do not
compile it at all". A selection by target kind — --lib --bins — leaves
tests/ out for the sound reason that an integration test needs a live
runtime; the unsound part is that the compiler then never looks at it
either, so it rots against the code it covers and is worthless at the
moment someone reaches for it. One such test in this repo had not compiled
for weeks (its helper constructed a struct that had since grown a field),
and nothing anywhere said so.
A map rather than a list: a test that compiles but never runs reads as coverage and is not, so the type makes "not run, and here is why" the only expressible form.
features: string[]
property
Features to enable (--features a,b).
jobs: number
property
Cap cargo's parallelism (-j N). Left unset, cargo uses every core.
Worth setting for a large workspace. Peak memory scales with job count, so a 32-way compile can exceed the memory a build is allowed and be killed for it — which surfaces as a mysterious signal rather than as "out of memory". Fewer jobs is a little slower and finishes.
lib: boolean
property
--lib — run the crate library's unit tests.
noDefaultFeatures: boolean
property
Turn off the crate's default features (--no-default-features).
noFailFast: boolean
property
--no-fail-fast — keep going past a failing test binary. Without it
one red crate silently suppresses every later crate's results, and the
report still looks complete, just shorter.
package: string
property
Restrict the command to a single workspace package (-p <pkg>).
Right for an artifact, since a binary comes from exactly one package.
Think twice for anything that tests: naming packages by hand is how a
crate quietly ends up tested nowhere, and a crate whose tests never ran
looks exactly like a crate whose tests pass. Prefer
CargoConfig.workspace, which cannot leave a crate out because it
never enumerates them.
profile: string
property
Which cargo profile to build ("dev" by default, or "release", or a
profile the crate defines itself).
resources: DagResources
property
What this one command's run is admitted against and held to, overriding
CargoConfig.resources. Commands differ by a lot — a check is
not a test --no-run, which is not a release build — and a grant is
both a ceiling and a reservation, so asking for the heaviest command's
budget everywhere would needlessly stop builds running side by side.
See DagResources.
sccache: boolean
property
false runs this one command without the node's shared compile cache,
whatever CargoConfig.sccache says. true cannot switch it on for
a builder that turned it off — the builder's setting is the ceiling.
services: Record<string, Pod>
property
Background services the tests talk to, keyed by id — an etcd for a
clustering suite, a database for a repository one. Each is started before
the run, kept up while it lasts, and stopped after; see
Pod.service.
They share the test pod's network namespace — the one its DAG runs in,
loopback included — so a service is reachable on 127.0.0.1:<port>.
Give each one a Pod.waitHealthy probe: without it the tests start
as soon as the service pod exists, which is earlier than it is
listening, and the suite goes red intermittently on whichever machine is
busiest.
This is what turns a suite that was #[ignore]d for want of a dependency
into one that runs — an ignored test compiles and covers nothing.
See Pod.
target: string
property
Cross-compile for a target triple (--target <triple>). The triple must
be installed in the image — see CargoToolchainOptions.targets.
test: string[]
property
--test <name> for each entry — the named integration tests, for when
only some of tests/ can run here and enumerating is the point.
tests: boolean
property
--tests — run every tests/ integration test.
timeoutSecs: number
property
Wall-clock limit in seconds, after which the command is killed and the build fails.
Without one, a wedged test does not fail the build — it hangs it, and a build that never returns is far more annoying to diagnose than one that fails. Omit for no limit.