From beagle-rust
Reviews Rust test code for unit/integration structure, tokio async tests, assertions, mocking, fixtures, isolation, and error paths. Use for _test.rs files and #[cfg(test)] modules.
npx claudepluginhub existential-birds/beagle --plugin beagle-rustThis skill uses the workspace's default tool permissions.
1. **Check test organization** — Unit tests in `#[cfg(test)]` modules, integration tests in `tests/` directory
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
#[cfg(test)] modules, integration tests in tests/ directory#[tokio::test] for async tests, proper runtime configurationReport findings as:
[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.
| Issue Type | Reference |
|---|---|
| Unit tests, assertions, naming, snapshots, rstest, doc tests | references/unit-tests.md |
| Integration tests, async testing, fixtures, test databases | references/integration-tests.md |
#[cfg(test)] mod tests within source filestests/ directory (one file per module or feature)use super::* in test modules to access parent module itemstest_<function>_<scenario>_<expected>#[tokio::test] used for async test functions#[tokio::test(flavor = "multi_thread")] when testing multi-threaded behaviorblock_on inside async tests (use .await directly)assert_eq! / assert_ne! used for value comparisons (better error messages than assert!)matches! macro used for enum variant checkingmatches! or pattern matching, not string comparisonResult::Err variants tested, not just happy paths#[should_panic] used sparingly — prefer Result-returning teststest_happy_path)mod blocks for organization<function>_should_<behavior>_when_<condition>cargo insta used for complex structural output (JSON, YAML, HTML, CLI output)snapshots/ directoryassert_eq!, not snapshotsrstest used to avoid duplicated test functions for similar inputs#[rstest] with #[case::name] attributes for descriptive parametrized tests#[fixture] used for shared test setup when multiple tests need same construction#[case(1)])#[rstest] #[tokio::test] for async parametrized tests/// # Examples with runnable code# to keep examples cleancargo test --doc passes (nextest doesn't run doc tests)#[should_panic] without expected message (catches any panic, including wrong ones)unwrap() in test setup that hides the real failure locationassert!(x == y) instead of assert_eq!(x, y) (worse error messages)proptest or quickcheckunwrap() / expect() in tests — Panicking on unexpected errors is the correct test behavioruse super::* in test modules — Standard pattern for accessing parent items#[allow(dead_code)] on test helpers — Helper functions may not be used in every testclone() in tests — Clarity over performanceassert! for boolean checks — Fine when the expression is clearly boolean (.is_some(), .is_empty())unwrap() on Result-returning test functions — Propagating with ? is also fine but not requiredLoad and follow beagle-rust:review-verification-protocol before reporting any issue.