xiaohongshu
xiaohongshu
chicago-tdd-pattern
Master Chicago TDD (state-based testing). Create tests that verify observable behavior with real collaborators. Use chicago-tdd-tools 1.4.0 AAA pattern. When writing tests, verifying implementation correctness, improving test quality, or analyzing test coverage. Covers: unit tests, integration te...
Full skill instructions
Chicago TDD = State-based testing with real collaborators
Verify observable behavior changes:
NOT internal implementation, method calls, or mocks (except London TDD in tests).
#[test]
fn test_feature() {
// ARRANGE: Set up real objects (no mocks)
let manager = LockfileManager::new(temp_dir.path());
// ACT: Call the public API being tested
manager.upsert("pkg", "1.0.0", "sha256", "url").unwrap();
// ASSERT: Verify observable state changed
let entry = manager.get("pkg").unwrap().unwrap();
assert_eq!(entry.version, "1.0.0"); // State changed ✓
}
Location: src/module.rs with #[cfg(test)] module
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_cache_insertion() {
// Arrange
let mut cache = Cache::new();
// Act
cache.insert("key", "value");
// Assert
assert_eq!(cache.get("key"), Some("value"));
}
}
Focus: Single responsibility, fast execution, deterministic results
Location: crates/*/tests/ directory
// tests/integration_test.rs
#[test]
fn test_full_pipeline() {
let config = Config::load("test.toml").unwrap();
let result = generate(&config).unwrap();
assert!(result.contains("generated code"));
assert!(Path::new("output.rs").exists());
}
Focus: Real filesystem, file I/O, full workflows
Location: crates/ggen-e2e/tests/ with testcontainers
#[tokio::test]
async fn test_with_docker() {
let container = RustContainer::default().start().await.unwrap();
let output = container.exec("cargo make test").await.unwrap();
assert!(output.contains("test result: ok"));
}
Focus: Real containers, actual system behavior, byte-for-byte validation
Tests should catch code mutations (changes):
cargo make test-audit mutations
# Mutation: Change == to !=
let x = 5;
if x == 5 { } → if x != 5 { }
# Good test catches this:
assert_eq!(result, 5); // Would fail if == changed to !=
Surviving mutations indicate weak tests - add more assertions.
Count assertions per function:
#[test]
fn test_parsing() {
// Arrange
let input = "key: value";
// Act
let result = parse(input).unwrap();
// Assert: Multiple assertions per test ✓
assert_eq!(result.key, "key"); // Assertion 1
assert_eq!(result.value, "value"); // Assertion 2
assert!(result.valid()); // Assertion 3
}
Low assertion density = incomplete testing.
Tests passing when implementation broken:
// ❌ BAD: Test passes even if add() is broken
#[test]
fn test_add() {
let result = add(2, 3);
// Missing assertion!
}
// ✓ GOOD: Test actually verifies behavior
#[test]
fn test_add() {
let result = add(2, 3);
assert_eq!(result, 5); // Catches bugs ✓
}
ALLOWED in test/benchmark code:
#[test]
fn test_something() {
let obj = Object::new().unwrap(); // ✓ ALLOWED
assert_eq!(obj.value(), 42);
}
#[cfg(test)]
mod tests {
#[test]
fn test_error() {
let result = parse("invalid");
assert!(result.is_err()); // ✓ ALLOWED
}
}
#[bench]
fn bench_iteration(b: &mut Bencher) {
let data = setup().unwrap(); // ✓ ALLOWED in benches
b.iter(|| process(&data))
}
Rationale: Tests should fail fast on setup errors. Don't hide test issues.
// ✓ Good: Each assertion tests one thing
#[test]
fn test_user_creation() {
let user = User::new("Alice", "[email protected]").unwrap();
assert_eq!(user.name, "Alice"); // Tests name
assert_eq!(user.email, "[email protected]"); // Tests email
assert!(user.valid()); // Tests validity
}
// ❌ Bad: Combined assertions hide failures
#[test]
fn test_user_creation() {
let user = User::new("Alice", "[email protected]").unwrap();
assert!(user.name == "Alice" && user.email == "[email protected]");
// If either fails, both fail
}
// ✓ Good: Separate tests for each error
#[test]
fn test_parse_empty_input_error() {
let result = parse("");
assert!(result.is_err());
assert_eq!(result.unwrap_err(), Error::EmptyInput);
}
#[test]
fn test_parse_invalid_syntax_error() {
let result = parse("invalid {syntax");
assert!(result.is_err());
assert_eq!(result.unwrap_err(), Error::SyntaxError);
}
// ❌ Bad: Multiple error paths in one test
#[test]
fn test_parse_errors() {
// This test does too much
}
// ✓ Good: Name tells you what is tested
#[test]
fn test_cache_returns_most_recent_value() { }
#[test]
fn test_cache_evicts_lru_on_full() { }
#[test]
fn test_cache_handles_concurrent_access() { }
// ❌ Bad: Unclear what's being tested
#[test]
fn test_cache_1() { }
#[test]
fn test_cache() { }
use criterion::{black_box, criterion_group, criterion_main, Criterion};
fn bench_generation(c: &mut Criterion) {
c.bench_function("generate_small", |b| {
b.iter(|| generate(black_box("small_input")))
});
c.bench_function("generate_large", |b| {
b.iter(|| generate(black_box("large_input")))
});
}
criterion_group!(benches, bench_generation);
criterion_main!(benches);
Run benchmarks:
cargo make bench # Run all benchmarks
cargo make bench-compare # Compare versions
use proptest::prelude::*;
proptest! {
#[test]
fn test_parse_roundtrip(s in r#"[a-z]+""#) {
let parsed = parse(&s).unwrap();
let serialized = serialize(&parsed);
prop_assert_eq!(s, serialized);
}
}
Advantage: Tests many inputs automatically, catches edge cases.
| Framework | Purpose | Use When |
|---|---|---|
| chicago-tdd-tools 1.4.0 | AAA pattern | Writing unit tests |
| proptest 1.8 | Property-based | Testing invariants |
| criterion 0.7 | Benchmarking | Performance tracking |
| testcontainers 0.25 | E2E with docker | Integration testing |
| assert_cmd 2.0 | CLI testing | Command validation |
| assert_fs 1.1 | Filesystem testing | File operations |
| mockall 0.13 | London TDD mocking | Test-only mocking |
| insta 1.43 | Snapshot testing | Golden files |
# Quick unit tests only
cargo make test-unit # ~10s
# All tests
cargo make test # ~30s (120s escalation)
# Specific test
cargo test test_name # Single test
# With output
cargo test -- --nocapture # See println! output
# Benchmarks
cargo make bench # All benchmarks
cargo bench bench_name # Specific benchmark
# Mutation testing
cargo make test-audit mutations
✓ All tests pass ✓ Mutation score > 90% ✓ Assertion density > 1 per function ✓ No false positives ✓ Error paths tested ✓ Chicago TDD pattern used ✓ No flaky tests ✓ SLO timeouts met
// WRONG: Testing internal detail
#[test]
fn test_cache_internal_structure() {
let cache = Cache::new();
assert_eq!(cache.data.capacity(), 100); // Wrong!
}
// CORRECT: Test observable behavior
#[test]
fn test_cache_stores_and_retrieves() {
let cache = Cache::new();
cache.insert("key", "value");
assert_eq!(cache.get("key"), Some("value"));
}
// WRONG: Mocks hide real behavior
#[test]
fn test_with_mock() {
let mut mock = MockService::new();
mock.expect_call().returning(|| 42);
// Mock doesn't test real behavior!
}
// CORRECT: Use real objects
#[test]
fn test_with_real_service() {
let service = RealService::new();
let result = service.call();
assert_eq!(result, 42); // Tests real behavior ✓
}
// WRONG: Test runs but doesn't verify
#[test]
fn test_something() {
let result = do_something(); // Missing assertion!
}
// CORRECT: Assert expected behavior
#[test]
fn test_something() {
let result = do_something();
assert_eq!(result, expected); // Verifies behavior ✓
}
reference.md - Detailed testing patternsexamples.md - Real-world test examplesxiaohongshu
technical spec
product ux expert
database patterns
Conduct multi-agent task orchestration and workflow coordination.
Initialize project with Conductor artifacts (product definition,
Expert in web animations, transitions, and motion design using Framer Motion and CSS
Creates Mermaid and ASCII diagrams for flowcharts, architecture, ERDs, state machines, mindmaps, and more. Use when user mentions diagram, flowchart, mermaid, ASCII diagram, text diagram, terminal diagram, visualize, C4, mindmap, architecture diagram, sequence diagram, ERD, or needs visual docume...
PostgreSQL bindings for H3 hexagonal grid system. Use when working with H3 cells in Postgres, including spatial indexing, geometry/geography integration, and raster analysis.
Context-Driven Development skill for projects using Conductor. Use this skill when you detect a `conductor/` directory in the project, when working on tasks defined in a `plan.md` file, or when the user asks about tracks, specs, or plans. Automatically applies TDD workflow, tracks task completion...
Display project status, active tracks, and next actions
Official Stakpak application containerization standard operating procedure, a step-by-step guidline to properly dockerize applications. This is a rule book curated by the Stakpak Team.
Generate, edit, and beat-sync AI video with leading models in one workspace.
The world's fastest calendar for remote work
Transform Your Design with AI Designer by ImgCreator.ai
Revolutionizing Video Production with AI-Powered Creativity
Extend an image past the frame and let AI fill the new aspect ratio.
Discover your celebrity doppelgänger with StarByFace!
ChainClarity explains 700+ crypto whitepapers in plain English, with layered summaries, comparisons, research tools, alerts, and a $4.99 Pro plan.
Opus.ai: Revolutionize Your Web Experience