Keep the broken input before you fix the bug
Capture a small regression fixture before changing code or asking an agent for a fix. Prove that the test detects the original failure and preserves the real requirement.
Rust builds, tests, and measurements
Keep failing inputs, diagnose build inputs, and compare performance with observable controls. Each guide gives a concrete reproduction, the resulting decision, and the limits of the evidence.
A test should fail for the reason you meant
An is_err assertion can pass because the database is unreachable. Check the intended error category and the stored outcome so unrelated failures cannot make a negative test green.
Don't fix a flaky test with a longer sleep
Replace timing guesses with observable readiness and controlled time. Keep real transport deadlines separate from a deterministic retry-policy test.
Don't put a timestamp in the dependency cache key
A run timestamp makes every dependency cache key different. Key reusable inputs deliberately and let Cargo validate artifacts without treating a cache hit as correctness evidence.
Check the lockfile change before blaming the new Rust compiler
A compiler upgrade and a dependency update are two changes. Compare compatible toolchain and lockfile combinations before assigning a build regression to rustc.
Test generated code from an empty output directory
A generator can appear correct because old files remain in OUT_DIR. Check fresh and reused builds, declare inputs, and own cleanup of obsolete generated files.
Keep the debug symbols for the binary you actually shipped
Connect each Rust release to its executable, debug information, and source revision. Rebuilding the same commit later is not a reliable substitute for the shipped artifact.
Measure tail latency before raising request concurrency
More concurrent calls can raise throughput while making slow requests worse. Compare queue time, errors, and latency distributions under the same offered workload.
Change one performance variable at a time
An optimization comparison needs equivalent work. Hold inputs steady, separate implementation changes, and investigate interactions after establishing a trustworthy baseline.
Should generated API clients live in their own Rust crate?
Evaluate a crate boundary around a generated Rust client using representative edits. Compare incremental reuse with clean-build and generic-code costs before splitting the workspace.