Skip to content
Русский

The core/tests/ harness

Most differential tests render on the software adapter (prefer_software) so they hold on any GPU; the exceptions say so below. That adapter is whichever software rasterizer the platform ships: lavapipe (Mesa’s software Vulkan) on Linux, WARP on Windows, and nothing on macOS.

The reference adapter is lavapipe, on the Arch reference machine (ADR-0242). Every golden baseline is captured and asserted there, and a reading this page gives without naming its rasterizer is a lavapipe reading. WARP still runs the rest of the software suite on the Windows CI arm, so the page also carries WARP readings. Each one says so, and one that nobody has re-taken on lavapipe is marked unverified on lavapipe as of 2026-10-06: a WARP measurement does not travel to lavapipe by renaming it.

Run the whole suite:

Terminal window
cargo nextest run -p rlx-core # what CI runs (per-test process isolation)
cargo test -p rlx-core # single binaries only — see the caveat below

Most of these files share one test binary (ADR-0204). core/tests/suite/ and standalone/tests/suite/ each hold the files that need no binary of their own, as modules of a main.rs, so a test’s name carries its file: easing::…, and cargo nextest run -p rlx-core --test suite easing:: runs one file’s tests. A file stays a top-level tests/*.rs when a binary() selector in .config/nextest.toml names it (the GPU suites below that -P fast excludes, and the clock-reading tests scheduled alone), when it reads the clock, or when it reads a process-level quantity such as its own memory. The rule for which is which lives in core/tests/suite/main.rs, and hygiene.rs fails on a clock exemption inside either suite/.

Use nextest for the whole suite. preset’s zero-allocation assertion is not the reason: its allocator hook counts per thread, so a concurrently-running test’s allocations never reach the count, under either runner and inside the shared suite binary alike.

The reason is that stock cargo test runs a binary’s tests as threads in one process, which the GPU tests do not survive. Several of them build and drop a Renderer (and so a wgpu device) concurrently, and the driver aborts the process with STATUS_ACCESS_VIOLATION — transition’s tests every run on WARP, --lib intermittently at teardown, --lib render::post since Plan 0035 (WARP readings, unverified on lavapipe as of 2026-10-06). This is a runner artifact, not a failing test: the same binaries pass in full under cargo nextest run, which gives each test its own process. If a cargo test invocation aborts with 0xc0000005, re-run it under nextest (or -- --test-threads=1) before concluding anything about coverage.

Tests that need a real GPU (background_composite, and the in-crate dual-live dissolve check in render/mod.rs) skip themselves when only a software rasterizer is present, per ADR-0016. WARP mis-renders both: the fullscreen-scene + background pipeline set, and — once a dissolve allocates its blend targets mid-run — what the feedback trails stage resolves to. Both are WARP readings, unverified on lavapipe as of 2026-10-06; the skips key on any software adapter, so they hold on lavapipe too until someone measures it.

In this section

Built from f4f807a at version 0.178.0. This site tracks main and is not versioned per release.