Days

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-output

If 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:rest

Before 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 order

Planner 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-output

On 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_equal

Adding 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-output

Add 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-output

The 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 -- --list

Metal 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.

On this page