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: 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'

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

単体テスト

モジュールレベルのテスト整理

// 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", "[email protected]").unwrap();
        assert_eq!(user.display_name(), "Alice");
        assert_eq!(user.email, "[email protected]");
    }

    #[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);                                    // 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 の戻り値のテスト

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

パニックのテスト

#[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() {

…