Rust TDD ワークフロー

TDD の 3 つの法則

1. 失敗するテストなしに本番コードを書かない
2. 失敗する程度のテストのみを書く (コンパイルエラーを含む)
3. 失敗するテストをパスさせる最小限の本番コードのみを書く

サイクル: RED (テスト失敗) -> GREEN (最小限でパス) -> REFACTOR (整理、cargo test)

Red-Green-Refactor のステップ

1. 同じファイルの #[cfg(test)] mod tests にテストを記述
2. cargo test MODULE::tests::test_name  -- 失敗する必要あり (red)
3. 関数に最小限の実装を追加
4. cargo test MODULE::tests::test_name  -- パスする必要あり (green)
5. 必要に応じてリファクタ、cargo test を再実行 (green を維持)
6. cargo fmt && cargo clippy --all-targets && cargo test  (最終チェック)

ステップ 2 をスキップしないこと。テストが即座にパスする場合、何もテストしていない。

Rust の慣用的なテストパターン

パターン	用途	使用時
Arrange-Act-Assert	すべてのテストの基本構造	常に
assert_eq! / assert!	直接比較 / ブール値	確定的な値
assert!(result.is_err())	エラーパスのテスト	無効な入力
Result<()> の戻り型	? 演算子を使うテスト	フォールバル関数
#[should_panic]	予期されるパニック	不変式、前置条件
tempfile::NamedTempFile	ファイル/I/O テスト	ファイルシステム依存コード

コード種別別パターン

コード種別	テストパターン	例
純粋関数 (str -> str)	入力リテラル -> 出力をアサート	assert_eq!(truncate("hello", 3), "...")
パース/フィルタリング	生文字列 -> フィルタ -> contains/not-contains	assert!(filter(raw).contains("expected"))
バリデーション/セキュリティ	境界入力 -> ブール値をアサート	assert!(!is_valid("../etc/passwd"))
エラーハンドリング	不正な入力 -> is_err()	assert!(parse("garbage").is_err())
Struct/enum のラウンドトリップ	構築 -> シリアライズ -> デシリアライズ -> 比較	assert_eq!(from_str(to_str(x)), x)

命名規則

test_{関数名}_{シナリオ}
test_{関数名}_{入力型}

例: test_truncate_edge_case, test_parse_invalid_input, test_filter_empty_string

Pure TDD を使わない場合

• Command::new() を呼び出す関数 -> 実行ではなくパーサーをテスト
• std::process::exit() -> まず Result にリファクタ、その後 Result をテスト
• 直接 I/O (SQLite、ネットワーク) -> tempfile/mock を使用するか、純粋ロジックを別途テスト
• Main/CLI の配線 -> 統合テスト/スモークテストでカバー

プリコミットゲート

cargo fmt --all --check
cargo clippy --all-targets
cargo test

3 つ全てがパスする必要があります。例外なし。正当な理由がない限り #[allow(...)] は不可。