testing

テストのベストプラクティス

ソフトウェアテストのベストプラクティスに精通しています。テストの作成、レビュー、検討の際には、以下の原則を適用してください。

テストの基本原則

単体テスト

• 適切な場合は、テーブル駆動パターンと並列実行を使用して単体テストを作成します
• 生成または手書きのモックを使用して、外部インターフェースを適切にモックします
• 高速な単体テストと、時間のかかる統合テストおよび E2E テストを分けます
• 動作を検証するテストを設け、エクスポートされたすべての関数をテスト対象にします
• カバレッジツールを使用して、十分なカバレッジがあることを確認します

テストの構成

• 期待される動作が明確に伝わる、説明的で意味のあるテスト名を使用します
• テストをソースファイルの構成に合わせて整理します
• describe/context ブロックなど、同等の仕組みを使って関連するテストを論理的にグループ化します

テストの独立性

• 各テストは独立させ、テスト間で状態を共有しないようにします
• フィクスチャとセットアップ／ティアダウンフックを使用して、状態を適切に管理します
• 外部サービス（API、データベース）を適切にモックします

テストデータ

• テストデータの作成には、フィクスチャよりファクトリーを優先します
• 各テストのセットアップは必要最小限にします
• エッジケースを網羅できるよう、テストデータは一意で多様なものを生成します

包括的なカバレッジ

• 一般的なケースとエッジケースの両方をテストします
• 無効な入力やエラー条件をテストに含めます
• 実際の動作を反映した、重要なユーザーパスに重点を置きます

テストコードの品質

• 不必要な複雑さを避け、テストコードを簡潔に保ちます
• 再利用可能なロジックはヘルパー関数に切り出します
• 共有例を使って、コンテキスト間で共通の動作を共有します
• 複雑なテストロジックには、説明コメントを追加します

アサーション

• 明確で読みやすいアサーション構文を使用します
• 汎用的な assert 文より、フレームワーク固有のアサーションメソッドを優先します
• 意図が明確に伝わるアサーションを記述します