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

// RED: 最初にテストを書き、プレースホルダーとして todo!() を使用
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 → 'not yet implemented' でパニック

// GREEN: todo!() を最小限の実装で置き換える
pub fn add(a: i32, b: i32) -> i32 { a + b }
// cargo test → PASS、その後、テストを通したままリファクター

ユニットテスト

モジュールレベルのテスト構成

// 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"));
    }
}

アサーションマクロ

assert_eq!(2 + 2, 4);                                    // 等値性
assert_ne!(2 + 2, 5);                                    // 不等性
assert!(vec![1, 2, 3].contains(&2));                     // ブール値
assert_eq!(value, 42, "expected 42 but got {value}");    // カスタムメッセージ
assert!((0.1_f64 + 0.2 - 0.3).abs() < f64::EPSILON);   // 浮動小数点数比較

エラーおよびパニックテスト

Result の戻り値をテストする

#[test]
fn parse_returns_error_for_invalid_input() {
    let result = parse_config("}{invalid");
    assert!(result.is_err());

    // 特定のエラーバリアントをアサート
    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(()) // ? が Err を返すとテストが失敗
}

パニックをテストする

#[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];
}

統合テスト

ファイル構造

my_crate/
├── src/
│   └── lib.rs
├── tests/              # 統合テスト
│   ├── api_test.rs     # 各ファイルは独立したテストバイナリ
│   ├── db_test.rs
│   └── common/         # 共有テストユーティリティ
│       └── mod.rs

統合テストを書く

// 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 を使用する

#[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 を使用したパラメータ化テスト

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);
}

// フィクスチャ
#[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()));
}

テストヘルパー

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

    /// 適切なデフォルト値でテストユーザーを作成します。
    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 を使用したプロパティベーステスト

基本的なプロパティテスト

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]);
        }
    }
}

カスタムストラテジー

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 を使用したモッキング

トレイトベースのモッキング

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());
}

ドックテスト

実行可能なドキュメント

/// 2 つの数値を加算します。
///
/// # 例
///
/// ```
/// 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
}

/// コンフィグ文字列を解析します。
///
/// # エラー
///
/// 入力が有効な TOML でない場合、`Err` を返します。
///
/// ```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 を使用したベンチマーク

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

[[bench]]
name = "benchmark"
harness = false

// 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);

テストカバレッジ

カバレッジの実行

# インストール: cargo install cargo-llvm-cov (または CI で taiki-e/install-action を使用)
cargo llvm-cov                    # サマリー
cargo llvm-cov --html             # HTML レポート
cargo llvm-cov --lcov > lcov.info # CI 用 LCOV フォーマット
cargo llvm-cov --fail-under-lines 80  # しきい値以下の場合は失敗

カバレッジターゲット

コードの種類	ターゲット
重大なビジネスロジック	100%
パブリック API	90%+
一般的なコード	80%+
生成 / FFI バインディング	除外

テストコマンド

cargo test                        # すべてのテストを実行
cargo test -- --nocapture         # println 出力を表示
cargo test test_name              # パターンに一致するテストを実行
cargo test --lib                  # ユニットテストのみ
cargo test --test api_test        # 統合テストのみ
cargo test --doc                  # ドックテストのみ
cargo test --no-fail-fast         # 最初のエラー時に停止しない
cargo test -- --ignored           # 無視されたテストを実行

ベストプラクティス

推奨:

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

非推奨:

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

CI 統合

# 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

記憶しておくこと: テストはドキュメントです。コードの使用方法を示します。明確に書き、常に最新の状態に保ってください。