succinctly: Skill for Claude Code

Testing Skill

Guidelines for writing effective tests that actually verify correctness.

Where a new yq/jq CLI test goes (#4329)

Do not append to the end of tests/yq_cli_tests.rs or tests/jq_cli_tests.rs: they are 70k and 160k lines, and an append at EOF conflicts with every other PR that does the same (about nine a day). Put the test for issue N in tests/yq_cli/iN.rs (or tests/jq_cli/iN.rs) and edit nothing else: the directory's mod.rs declares every file in it with automod::dir! (#5697), so there is no mod iN; list for two PRs to conflict on. Reach the shared helpers with use crate::{run_yq_stdin, ...};. The directory is compiled into the existing test binary (no new target, no extra link time). cargo fmt cannot follow a macro-generated mod: format a new file with scripts/fmt-per-issue.sh --fix (CI and scripts/pre-push.sh check with it). An incremental cargo test does not see a new file until mod.rs is touched (touch tests/jq_cli/mod.rs). A test for a behaviour an existing test already pins is better extended in place; do not move existing tests.

Critical Anti-Pattern: Success-Only Tests

Never write tests that only check for successful execution without verifying output.

Bad Example (YAML test suite bug)

// BAD: Only checks parse success, not correctness
#[test]
fn test_sequence_of_mappings() {
    let yaml = b"- name: Alice\n  age: 30";
    let result = YamlIndex::build(yaml);
    assert!(result.is_ok());  // Parser could return completely wrong structure!
}

This test passed even when the parser produced ["name", "Alice", "age", 30] instead of [{"name": "Alice", "age": 30}].

Good Example

// GOOD: Verifies actual output matches expected
#[test]
fn test_sequence_of_mappings() {
    let yaml = b"- name: Alice\n  age: 30";
    let index = YamlIndex::build(yaml).unwrap();
    let json = index.to_json(yaml);
    assert_eq!(json, r#"[{"name":"Alice","age":30}]"#);
}

Test Generator Pitfalls