rust-testing

原文涵盖的主题

• Rust テストパターン
• 使用場面
• 動作原理
• RustのTDDワークフロー
• RED-GREEN-REFACTOR サイクル
• Rustでの段階的TDD
• 単体テスト
• モジュールレベルのテスト整理

TDD方法論に従って信頼性が高く保守しやすいテストを書くための包括的なRustテストパターン。 新しいRustの関数、メソッド、またはトレイトを書く場合 既存のコードにテストカバレッジを追加する場合 パフォーマンスクリティカルなコードのベンチマークを作成する場合 入力検証にプロパティベーステストを実装する場合 RustプロジェクトでTDDワークフローに従う場合 1. ターゲットコードを特定する — テストする関数、トレイト、またはモジュールを見つける 2. テストを書く — #[cfg(test)] モジュール内で #[test] を使用、rstest でパラメータ化テスト、または proptest でプロパティベーステスト 3. 依存関係をモックする — mockall を使用してテスト対象のユニットを分離する 4. テストを実行する (RED) — テストが期待通りに失敗することを確認する 5. 実装する (GREEN) — テストを通過するための最小限のコードを書く 6. リファクタリングする — テストを通過したまま、コードを改善する 7. カバレッジを確認する — cargo-llvm-cov を使用し、80%以上を目標にする | コードの種類 | 目標 | |-----------|--------| | クリティカルなビジネスロジック | 100% | | パブリックAPI | 90%以上 | | 汎用コード | 80%以上 | | 生成済み / FFIバインディング | 除外 | すべきこと： まずテストを書く (TDD) 単体テストには #[cfg(test)] モジュールを使用する 実装ではなく動作をテストする シナリオを説明する記述的なテスト名を使用する より良いエラーメッセージのために assert! より asserteq! を優先する クリーンなエラー出力のために Result を返すテストでは ? を使用する テストを独立させる——共有の可変状態なし すべきでないこと： Result::iserr() をテストできる場合に #[shouldpanic] を使用する すべてをモックする——可能なら統合テストを優先する フレーキーなテストを無視する——修正または分離する テストで sleep() を使用する——チャンネル、バリア、または tokio::time::pause() を使用する エラーパスのテストをスキップする 覚えておくこと：テストはドキュメントである。コードをどのように使うべきかを示している。明確に書き、最新の状態を保つこと。