Testing
The default test matrix, planner equality, and the byte-identity and fixture gates.
Scope: Days AGO, plus the legacy and cross-engine packages in the default matrix. Tests live under executor/tests/, tests/, legacy/tests/, and validation/tests/.
Default workspace matrix
cargo test -p days-executor -- --show-output
cargo test -p days --features test -- --show-output
cargo test -p days-legacy --features test -- --show-output
cargo test -p days-validation --features test -- --show-outputIf cargo-nextest is installed, the same package surface can be selected with cargo nextest run. Do not use --all-features on a machine that cannot build both device toolchains.
cargo xtask audit runs two structural checks: only days-validation may depend on days-legacy, as a test-only dev-dependency; and every backend feature gate in executor/src must match a registered predicate and occurrence count.
CI test shards
CI runs the four commands above, in debug, as parallel test-shard jobs. .github/test-shards.sh
holds the layout: five shards, each a list of units, where a unit is a whole package, one
integration-test target (days:p15_roce_fixtures), or days:rest, every days target not named
in another unit. rest first runs the package's default --no-run build, so every example and
test target still compiles as the unsharded command compiled it, then runs the remaining targets,
then the doctests.
lowering-budget days:collective_lowering_budget
width-via-load-legacy days:width_via_load_fixtures days:p14_dcqcn_pfc_fixtures days-legacy
roce days:p15_roce_fixtures days:p15_roce_collectives
validation-executor days-validation days-executor
rest days:restBefore any shard runs, a test-plan job checks the layout against cargo metadata: every target
the four commands build or run must belong to exactly one shard, every test named in the layout
must exist, and every workspace member must be tested or listed as untested (xtask, which CI
did not test before either). A new test file under tests/ therefore lands in rest with no
layout change, and the check fails on a target in no shard or in two. The required test check is
an aggregate job: it passes when every shard passed, or when the shards were skipped because a
pull request changed only docs/**, logs/** or **.md; a shard that failed, was cancelled or
timed out fails it. Each shard has the 75-minute timeout the single job had.
The script runs locally too (it needs jq):
.github/test-shards.sh plan # check the layout; print the shard names as JSON
.github/test-shards.sh list # print "shard package target" for every target
.github/test-shards.sh run roce # run one shard's cargo commands in orderPlanner equality
The planner equality test compares the device planners' precomputed plans with the retained earlier planner. It builds plans on the host and needs test plus one device feature:
# Apple Metal
cargo test -p days --features test,metal \
--test planner_bit_equal -- --show-output
# CUDA (the build needs a CUDA 13 nvcc)
cargo test -p days --features test,cuda \
--test planner_bit_equal -- --show-outputOn a host without nvcc, the cuda-planner-test feature runs the same test for the CUDA planner. It enables test, and the executor's build script writes an empty placeholder instead of compiling CUDA kernels, so the test only builds plans on the host:
cargo test -p days --features cuda-planner-test --test planner_bit_equalAdding cuda-test-hooks to that build compiles the kernels again, so it needs nvcc.
TCP corpus byte identity
This ignored test lowers the committed TCP corpus and compares the CPU engine and each compiled device backend with the Scalar oracle:
cargo test --release -p days-validation --features test \
--test tcp_corpora \
full_tcp_corpora_are_byte_identical_across_available_backends \
-- --ignored --exact --show-outputAdd metal on Apple or cuda on a CUDA host to include that device, for example --features test,metal. The comparison removes device-omitted diagnostic planes, then requires the complete remaining RunResult to be byte-identical.
E5 fixture gates
The fast check regenerates the E5 flow sets and compares them with the committed fixtures:
cargo test -p days --features test --test e5_wide_tcp_fixtures \
e5_generator_reproduces_committed_flow_set_fixtures -- --exact --show-outputThe same test target contains ignored full-run gates: Scalar count and trajectory gates, CPU completion anchors, and a protocol golden-vector gate. Building it with --features test,metal-test-hooks adds ignored Metal completion gates. List the exact names before selecting a long run:
cargo test -p days --features test --test e5_wide_tcp_fixtures -- --listMetal on Apple7-family GPUs
The Metal backend refuses Apple M1-family GPUs (Apple7); see Installation. To investigate the incorrect code generation, DAYS_METAL_ALLOW_APPLE7=1 skips the refusal and prints a warning on standard error. Results on such a GPU are known to be wrong, and a cold build of the days_round pipeline takes about ten minutes.
Legacy Days
The legacy crate's feature-gated tests are listed on the Legacy Days page.