Agent skill

Rust Testing

by affaan-m in affaan-m/ECC

単体テスト、統合テスト、非同期テスト、プロパティベーステスト、モック、カバレッジを含むRustテストパターン。TDD方法論に従う。

MITAuto-check passedTesting & QA

Install Rust Testing

skills CLI
$ npx skills add affaan-m/ECC --skill rust-testing -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install affaan-m/ECC rust-testing --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/affaan-m/ECC.git skills-src && mkdir -p .claude/skills && cp -r skills-src/docs/ja-JP/skills/rust-testing .claude/skills/rust-testing && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
rust-testing
GitHub stars
275k
Token cost
~2.6k tokens
SKILL.md length
120 words
Files
1
Skills in repo
645
Repo updated
First seen
Licence
MIT

At a glance

単体テスト、統合テスト、非同期テスト、プロパティベーステスト、モック、カバレッジを含むRustテストパターン。TDD方法論に従う。

  • Works in 7 steps: ターゲットコードを特定する — テストする関数、トレイト、またはモジュールを見つける → テストを書く — #[cfg(test)] モジュール内で #[test]… → 依存関係をモックする — mockall を使用してテスト対象のユニットを分離する → …
  • Tasks that involve Test-driven development
  • SKILL.md covers 使用場面, 動作原理, RustのTDDワークフロー and 単体テスト, plus 9 more sections
  • Calls cargo

What it does

Rust Testing is an agent skill from affaan-m/ECC. 単体テスト、統合テスト、非同期テスト、プロパティベーステスト、モック、カバレッジを含むRustテストパターン。TDD方法論に従う。

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering Test-driven development. It works with Rust. The repository describes itself as: The agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond. The licence is MIT.

When your agent uses it

  • Tasks that involve Test-driven development

Example prompts

  • “/rust-testing”

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. ターゲットコードを特定する — テストする関数、トレイト、またはモジュールを見つける
  2. テストを書く — #[cfg(test)] モジュール内で #[test] を使用、rstest でパラメータ化テスト、または proptest でプロパティベーステスト
  3. 依存関係をモックする — mockall を使用してテスト対象のユニットを分離する
  4. テストを実行する (RED) — テストが期待通りに失敗することを確認する
  5. 実装する (GREEN) — テストを通過するための最小限のコードを書く
  6. リファクタリングする — テストを通過したまま、コードを改善する
  7. カバレッジを確認する — cargo-llvm-cov を使用し、80%以上を目標にする

What it can do on your machine

Read from SKILL.md and the folder at commit ef648e0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • cargo

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Rust Testing loads about 2.6k tokens when it runs. Until then it costs about 20 tokens; SKILL.md has 120 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~20
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from affaan-m/ECC at commit ef648e0, republished under its MIT licence (© affaan-m). 120 words, ~2,642 tokens.

Download SKILL.mdSave it as .claude/skills/rust-testing/SKILL.md (or your agent's skills folder).
name
rust-testing
description
単体テスト、統合テスト、非同期テスト、プロパティベーステスト、モック、カバレッジを含むRustテストパターン。TDD方法論に従う。
origin
ECC

Rust テストパターン

TDD方法論に従って信頼性が高く保守しやすいテストを書くための包括的なRustテストパターン。

使用場面

  • 新しいRustの関数、メソッド、またはトレイトを書く場合
  • 既存のコードにテストカバレッジを追加する場合
  • パフォーマンスクリティカルなコードのベンチマークを作成する場合
  • 入力検証にプロパティベーステストを実装する場合
  • RustプロジェクトでTDDワークフローに従う場合

動作原理

  1. ターゲットコードを特定する — テストする関数、トレイト、またはモジュールを見つける
  2. テストを書く — #[cfg(test)] モジュール内で #[test] を使用、rstest でパラメータ化テスト、または proptest でプロパティベーステスト
  3. 依存関係をモックする — mockall を使用してテスト対象のユニットを分離する
  4. テストを実行する (RED) — テストが期待通りに失敗することを確認する
  5. 実装する (GREEN) — テストを通過するための最小限のコードを書く
  6. リファクタリングする — テストを通過したまま、コードを改善する
  7. カバレッジを確認する — cargo-llvm-cov を使用し、80%以上を目標にする

RustのTDDワークフロー

RED-GREEN-REFACTOR サイクル
RED     → まず失敗するテストを書く
GREEN   → テストを通過する最小限のコードを書く
REFACTOR → テストを通過したままコードをリファクタリングする
REPEAT  → 次の要件に進む
Rustでの段階的TDD
rust
// RED: Write test first, use todo!() as placeholder
pub fn add(a: i32, b: i32) -> i32 { todo!() }

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_add() { assert_eq!(add(2, 3), 5); }
}
// cargo test → panics at 'not yet implemented'
rust
// GREEN: Replace todo!() with minimal implementation
pub fn add(a: i32, b: i32) -> i32 { a + b }
// cargo test → PASS, then REFACTOR while keeping tests green

単体テスト

モジュールレベルのテスト整理
rust
// src/user.rs
pub struct User {
    pub name: String,
    pub email: String,
}

impl User {
    pub fn new(name: impl Into<String>, email: impl Into<String>) -> Result<Self, String> {
        let email = email.into();
        if !email.contains('@') {
            return Err(format!("invalid email: {email}"));
        }
        Ok(Self { name: name.into(), email })
    }

    pub fn display_name(&self) -> &str {
        &self.name
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn creates_user_with_valid_email() {
        let user = User::new("Alice", "alice@example.com").unwrap();
        assert_eq!(user.display_name(), "Alice");
        assert_eq!(user.email, "alice@example.com");
    }

    #[test]
    fn rejects_invalid_email() {
        let result = User::new("Bob", "not-an-email");
        assert!(result.is_err());
        assert!(result.unwrap_err().contains("invalid email"));
    }
}
アサーションマクロ
rust
assert_eq!(2 + 2, 4);                                    // Equality
assert_ne!(2 + 2, 5);                                    // Inequality
assert!(vec![1, 2, 3].contains(&2));                     // Boolean
assert_eq!(value, 42, "expected 42 but got {value}");    // Custom message
assert!((0.1_f64 + 0.2 - 0.3).abs() < f64::EPSILON);   // Float comparison

エラーとパニックのテスト

Result の戻り値のテスト
rust
#[test]
fn parse_returns_error_for_invalid_input() {
    let result = parse_config("}{invalid");
    assert!(result.is_err());

    // Assert specific error variant
    let err = result.unwrap_err();
    assert!(matches!(err, ConfigError::ParseError(_)));
}

#[test]
fn parse_succeeds_for_valid_input() -> Result<(), Box<dyn std::error::Error>> {
    let config = parse_config(r#"{"port": 8080}"#)?;
    assert_eq!(config.port, 8080);
    Ok(()) // Test fails if any ? returns Err
}
パニックのテスト
rust
#[test]
#[should_panic]
fn panics_on_empty_input() {
    process(&[]);
}

#[test]
#[should_panic(expected = "index out of bounds")]
fn panics_with_specific_message() {
    let v: Vec<i32> = vec![];
    let _ = v[0];
}

統合テスト

ファイル構造
text
my_crate/
├── src/
│   └── lib.rs
├── tests/              # 統合テスト
│   ├── api_test.rs     # 各ファイルが独立したテストバイナリ
│   ├── db_test.rs
│   └── common/         # 共有テストユーティリティ
│       └── mod.rs
統合テストの書き方
rust
// tests/api_test.rs
use my_crate::{App, Config};

#[test]
fn full_request_lifecycle() {
    let config = Config::test_default();
    let app = App::new(config);

    let response = app.handle_request("/health");
    assert_eq!(response.status, 200);
    assert_eq!(response.body, "OK");
}

非同期テスト

Tokioの使用
rust
#[tokio::test]
async fn fetches_data_successfully() {
    let client = TestClient::new().await;
    let result = client.get("/data").await;
    assert!(result.is_ok());
    assert_eq!(result.unwrap().items.len(), 3);
}

#[tokio::test]
async fn handles_timeout() {
    use std::time::Duration;
    let result = tokio::time::timeout(
        Duration::from_millis(100),
        slow_operation(),
    ).await;

    assert!(result.is_err(), "should have timed out");
}

テスト整理パターン

rstest を使用したパラメータ化テスト
rust
use rstest::{rstest, fixture};

#[rstest]
#[case("hello", 5)]
#[case("", 0)]
#[case("rust", 4)]
fn test_string_length(#[case] input: &str, #[case] expected: usize) {
    assert_eq!(input.len(), expected);
}

// Fixtures
#[fixture]
fn test_db() -> TestDb {
    TestDb::new_in_memory()
}

#[rstest]
fn test_insert(test_db: TestDb) {
    test_db.insert("key", "value");
    assert_eq!(test_db.get("key"), Some("value".into()));
}
テストヘルパー関数
rust
#[cfg(test)]
mod tests {
    use super::*;

    /// Creates a test user with sensible defaults.
    fn make_user(name: &str) -> User {
        User::new(name, &format!("{name}@test.com")).unwrap()
    }

    #[test]
    fn user_display() {
        let user = make_user("alice");
        assert_eq!(user.display_name(), "alice");
    }
}

proptest を使用したプロパティベーステスト

基本的なプロパティテスト
rust
use proptest::prelude::*;

proptest! {
    #[test]
    fn encode_decode_roundtrip(input in ".*") {
        let encoded = encode(&input);
        let decoded = decode(&encoded).unwrap();
        assert_eq!(input, decoded);
    }

    #[test]
    fn sort_preserves_length(mut vec in prop::collection::vec(any::<i32>(), 0..100)) {
        let original_len = vec.len();
        vec.sort();
        assert_eq!(vec.len(), original_len);
    }

    #[test]
    fn sort_produces_ordered_output(mut vec in prop::collection::vec(any::<i32>(), 0..100)) {
        vec.sort();
        for window in vec.windows(2) {
            assert!(window[0] <= window[1]);
        }
    }
}
カスタムストラテジー
rust
use proptest::prelude::*;

fn valid_email() -> impl Strategy<Value = String> {
    ("[a-z]{1,10}", "[a-z]{1,5}")
        .prop_map(|(user, domain)| format!("{user}@{domain}.com"))
}

proptest! {
    #[test]
    fn accepts_valid_emails(email in valid_email()) {
        assert!(User::new("Test", &email).is_ok());
    }
}

mockall を使用したモック

トレイトベースのモック
rust
use mockall::{automock, predicate::eq};

#[automock]
trait UserRepository {
    fn find_by_id(&self, id: u64) -> Option<User>;
    fn save(&self, user: &User) -> Result<(), StorageError>;
}

#[test]
fn service_returns_user_when_found() {
    let mut mock = MockUserRepository::new();
    mock.expect_find_by_id()
        .with(eq(42))
        .times(1)
        .returning(|_| Some(User { id: 42, name: "Alice".into() }));

    let service = UserService::new(Box::new(mock));
    let user = service.get_user(42).unwrap();
    assert_eq!(user.name, "Alice");
}

#[test]
fn service_returns_none_when_not_found() {
    let mut mock = MockUserRepository::new();
    mock.expect_find_by_id()
        .returning(|_| None);

    let service = UserService::new(Box::new(mock));
    assert!(service.get_user(99).is_none());
}

ドキュメントテスト

実行可能なドキュメント
rust
/// Adds two numbers together.
///
/// # Examples
///
/// ```
/// use my_crate::add;
///
/// assert_eq!(add(2, 3), 5);
/// assert_eq!(add(-1, 1), 0);
/// ```
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

/// Parses a config string.
///
/// # Errors
///
/// Returns `Err` if the input is not valid TOML.
///
/// ```no_run
/// use my_crate::parse_config;
///
/// let config = parse_config(r#"port = 8080"#).unwrap();
/// assert_eq!(config.port, 8080);
/// ```
///
/// ```no_run
/// use my_crate::parse_config;
///
/// assert!(parse_config("}{invalid").is_err());
/// ```
pub fn parse_config(input: &str) -> Result<Config, ParseError> {
    todo!()
}

Criterionを使用したベンチマーク

toml
# Cargo.toml
[dev-dependencies]
criterion = { version = "0.5", features = ["html_reports"] }

[[bench]]
name = "benchmark"
harness = false
rust
// benches/benchmark.rs
use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn fibonacci(n: u64) -> u64 {
    match n {
        0 | 1 => n,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

fn bench_fibonacci(c: &mut Criterion) {
    c.bench_function("fib 20", |b| b.iter(|| fibonacci(black_box(20))));
}

criterion_group!(benches, bench_fibonacci);
criterion_main!(benches);

テストカバレッジ

カバレッジの実行
bash
# Install: cargo install cargo-llvm-cov (or use taiki-e/install-action in CI)
cargo llvm-cov                    # Summary
cargo llvm-cov --html             # HTML report
cargo llvm-cov --lcov > lcov.info # LCOV format for CI
cargo llvm-cov --fail-under-lines 80  # Fail if below threshold
カバレッジ目標
コードの種類目標
クリティカルなビジネスロジック100%
パブリックAPI90%以上
汎用コード80%以上
生成済み / FFIバインディング除外

テストコマンド

bash
cargo test                        # Run all tests
cargo test -- --nocapture         # Show println output
cargo test test_name              # Run tests matching pattern
cargo test --lib                  # Unit tests only
cargo test --test api_test        # Integration tests only
cargo test --doc                  # Doc tests only
cargo test --no-fail-fast         # Don't stop on first failure
cargo test -- --ignored           # Run ignored tests

ベストプラクティス

すべきこと:

  • まずテストを書く (TDD)
  • 単体テストには #[cfg(test)] モジュールを使用する
  • 実装ではなく動作をテストする
  • シナリオを説明する記述的なテスト名を使用する
  • より良いエラーメッセージのために assert! より assert_eq! を優先する
  • クリーンなエラー出力のために Result を返すテストでは ? を使用する
  • テストを独立させる——共有の可変状態なし

すべきでないこと:

  • Result::is_err() をテストできる場合に #[should_panic] を使用する
  • すべてをモックする——可能なら統合テストを優先する
  • フレーキーなテストを無視する——修正または分離する
  • テストで sleep() を使用する——チャンネル、バリア、または tokio::time::pause() を使用する
  • エラーパスのテストをスキップする

CI統合

yaml
# GitHub Actions
test:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: dtolnay/rust-toolchain@stable
      with:
        components: clippy, rustfmt

    - name: Check formatting
      run: cargo fmt --check

    - name: Clippy
      run: cargo clippy -- -D warnings

    - name: Run tests
      run: cargo test

    - uses: taiki-e/install-action@cargo-llvm-cov

    - name: Coverage
      run: cargo llvm-cov --fail-under-lines 80

覚えておくこと:テストはドキュメントである。コードをどのように使うべきかを示している。明確に書き、最新の状態を保つこと。

© affaan-m, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in docs/ja-JP/skills/rust-testing of affaan-m/ECC.

Open the folder on GitHubat commit ef648e0

Compare with similar skills

Rust Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Rust Testing compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Rust Testing this skillaffaan-m/ECC275k—~2.6kAutomated safety check: PassMIT
Rust TDD Workflowrtk-ai/rtk83k—~753Automated safety check: NotesApache-2.0
RTK Filter TDD in Rustrtk-ai/rtk83k—~1.9kAutomated safety check: NotesApache-2.0
TDDccusage/ccusage19k—~665Automated safety check: PassCustom licence
Implementmag123c/toktrack193—~353Automated safety check: PassMIT
Rust Testingkurealnum/dotfiles2906 repos~2.9kAutomated safety check: PassNone

Similar skills

  • Enforces red-green-refactor for Rust work, with idiomatic test patterns, a naming convention and a pre-commit gate of cargo fmt, clippy and test.

    83k GitHub stars~753 tokensUpdated yesterday
    Testing & QAAuto-check: notes
  • Enforces red-green-refactor for new RTK output filters in Rust, using real captured fixtures, snapshot tests with insta and token-savings assertions.

    83k GitHub stars~1.9k tokensUpdated yesterday
    Testing & QAAuto-check: notes
  • TDD

    ccusage/ccusage

    Guides t-wada Red-Green-Refactor TDD for ccusage logic changes.

    19k GitHub stars~665 tokensUpdated today
    Testing & QAAuto-check passed
  • Implement

    mag123c/toktrack

    TDD implementation (RED→GREEN→REFACTOR) → verify → review. An agent skill from mag123c/toktrack.

    193 GitHub stars~353 tokensUpdated 7 days ago
    Testing & QAAuto-check passed
  • Rust Testing

    kurealnum/dotfiles

    Rust testing patterns including unit tests, integration tests, async testing, property-based testing, mocking, and coverage.

    290 GitHub starsUsed in 6 repos~2.9k tokens
    Testing & QAAuto-check passed
  • Growing Outside In Systems

    lexler/skill-factory

    Drive feature development using Outside-In TDD with Hexagonal Architecture.

    239 GitHub starsUsed in 1 repo~1.9k tokens
    Testing & QAAuto-check passed

More from affaan-m/ECC

All 645 skills in this repo
  • Videodb

    affaan-m/ECC

    Ingest, index, search, edit, and monitor video and audio with the VideoDB Python SDK — upload from files, URLs, or RTSP feeds, build spoken and scene indexes with timestamped search and playable…

    275k GitHub starsUsed in 3 repos~3.5k tokens
    Auto-check: notes
  • Rules Distillation

    affaan-m/ECC

    Scans installed skills for principles that recur across them and proposes rule-file changes: append, revise, add a section, create a file or leave as covered.

    275k GitHub starsUsed in 2 repos~2.3k tokens
    Auto-check passed
  • Builds DRAFT counterparty agreements from one markdown template and a small JSON spec per party, with clauses picked by the party's role.

    275k GitHub stars~2.9k tokensUpdated 3 days ago
    Auto-check passed
  • Measures whether agents actually follow a skill, rule or agent definition by generating scenarios at three strictness levels and scoring tool-call traces.

    275k GitHub starsUsed in 1 repo~623 tokens
    Auto-check passed
  • Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills/commands/agents.

    275k GitHub stars~3.5k tokensUpdated 3 days ago
    Auto-check passed
  • Adds one optional external Codex critique that tries to break a council's decision draft, sent to OpenAI only after you consent.

    275k GitHub stars~1.5k tokensUpdated 3 days ago
    Auto-check passed

Works with

Categories

Questions about Rust Testing

What does Rust Testing do?

単体テスト、統合テスト、非同期テスト、プロパティベーステスト、モック、カバレッジを含むRustテストパターン。TDD方法論に従う。. Rust Testing is an agent skill from affaan-m/ECC.

When should I use Rust Testing?

Rust Testing fits situations like: tasks that involve Test-driven development.

How do I install Rust Testing in Claude Code?

Run `npx skills add affaan-m/ECC --skill rust-testing -a claude-code`. Or copy the skill folder (docs/ja-JP/skills/rust-testing in affaan-m/ECC) into .claude/skills/rust-testing in your project. Claude Code loads it when a task matches its description.

How do I install Rust Testing in Codex?

Run `npx skills add affaan-m/ECC --skill rust-testing -a codex`. Or copy the skill folder (docs/ja-JP/skills/rust-testing in affaan-m/ECC) into .agents/skills/rust-testing in your project. Codex loads it when a task matches its description.

Can I use Rust Testing in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add affaan-m/ECC --skill rust-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/rust-testing, .gemini/skills/rust-testing, .github/skills/rust-testing and .opencode/skills/rust-testing in your project.

What does Rust Testing need to run?

Going by SKILL.md and its folder, Rust Testing needs the command-line tools its instructions call (cargo).

Does Rust Testing access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Rust Testing safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Rust Testing use?

Rust Testing is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Rust Testing use?

About 2.6k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Rust Testing?

Skills that share tags, products or a category with Rust Testing: Rust TDD Workflow (rtk-ai/rtk, 83k stars), RTK Filter TDD in Rust (rtk-ai/rtk, 83k stars), TDD (ccusage/ccusage, 19k stars) and Implement (mag123c/toktrack, 193 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Rust Testing?

affaan-m (a GitHub user) maintains it in affaan-m/ECC, which has 275,023 GitHub stars. The repository holds 645 skills in this directory. The repository was last updated on October 5, 2026.

Source: affaan-m/ECC on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.