Use this skill when the user asks to "run tests", "test this", "check if tests pass", "cargo test", "run clippy", "lint this", "check formatting", "cargo fmt", "CI checks", "verify changes", "does this pass tests", "run the full check", "pre-commit check", or wants to verify that code changes are correct. Use this even when the user says something like "make sure this works" or "check for issues" in the context of code changes.
72
68%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/run-tests/SKILL.mdHow to run tests, lint, and verify changes in the cx CLI. This skill covers running only - for writing new tests, see the add-command skill.
| Command | What it does |
|---|---|
cargo test | Run all unit + integration tests |
cargo test <name> | Run tests matching a name substring |
cargo test -- --ignored | Run integration tests (filesystem-dependent, skipped by default) |
cargo fmt --check | Check formatting (no changes) |
cargo fmt | Auto-fix formatting |
cargo clippy --locked -- -D warnings | Lint with warnings-as-errors |
cargo build | Verify compilation |
This is the exact sequence CI runs on every PR. Run it before committing or creating a PR:
cargo fmt --check && cargo clippy --locked -- -D warnings && cargo test --lockedThe --locked flag ensures the lockfile is respected - this matches .github/workflows/test.yml and lint.yml exactly. CI runs tests on Ubuntu, macOS, and Windows.
Pick the right level of verification based on what changed:
.rs file - cargo test + cargo clippy --locked -- -D warningscargo fmt --check (or cargo fmt to auto-fix)Cargo.toml - full CI check (dependency changes affect everything)src/commands/<cmd>/api.rs) - run that command's tests first (cargo test alerts, cargo test dataprime), then the full suitecargo test <relevant_test_name>Target tests efficiently instead of running the entire suite:
cargo test alerts - all tests with "alerts" in the namecargo test --test dataprime - only the tests/dataprime/ integration test binary (input + output + query)cargo test --test dataprime input - only the input submodule of that binarycargo test config::tests - only the tests in the config modulecargo test metrics::tests - only metrics formatting testsClippy warnings - treated as errors via -D warnings. Fix every warning before committing. Common ones: unused variables, unnecessary clones, missing error handling.
Format failures - run cargo fmt to auto-fix. These never need manual intervention.
Deserialization test failures - usually means struct field names don't match JSON keys. Check that #[serde(rename_all = "camelCase")] is on response types and that #[serde(default)] is on Vec fields (the API sometimes omits empty arrays).
Compilation errors in tests - likely caused by changing a public function signature. Check callers in both src/ and tests/ directories.
Integration test failures (--ignored) - these depend on filesystem state (~/.cx/ config directory). They may fail if the local environment isn't set up. This is expected in CI where no config exists.
defdc4d
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.