01 / Behavioral framing
Design the test before writing its setup
The test section asks what the module does, what crosses its boundary, and which failure the test protects against. It then selects the cheapest level that catches that failure.
Source excerpt starting at line 85.85- **Design before you write.** Answer four questions first: what is the module86 for, what is its I/O contract, what failure am I guarding against, and what is87 the cheapest level that catches it (unit over integration over e2e)?
02 / Hard prohibitions
Separate kernel performance from correctness coverage
One-off performance work belongs in the kernel benchmark directory. Correctness belongs in the existing pytest suites, so the two kinds of evidence have explicit homes.
Source excerpt starting at line 95.95- **No one-off kernel benchmarks in `tests/`.** Put kernel perf work in96 `benchmarks/kernels/`; prove correctness in existing pytest suites.
03 / Verification by change type
Require model evaluations when behavior can change
Tests alone do not satisfy the guidance for changes affecting output, accuracy, or serving. The file asks for model evaluations and their results in the PR before a reviewer has to request them.
Source excerpt starting at line 97.97- **Run model evals for model-affecting changes.** Search `tests/evals/` or use98 `vllm bench` and include results in the PR — do not wait for reviewers to ask.
04 / Router files
Route native builds away from the default editable install
The default install starts with precompiled artifacts. C, C++, and CUDA changes instead follow the incremental compilation guide, making the distinction depend on the edited implementation.
Source excerpt starting at line 67.67For C/C++ or CUDA changes, follow the68[incremental compilation workflow](docs/contributing/incremental_build.md) to69configure and perform incremental builds.