コンテンツにスキップ

2. テストケース規定

このセクションでは、2.1 テスト戦略で定義された各テストを、具体的にどのように実装するかという技術的なルールを定めます。

開発者が実際にテストコードを記述する際の、命名規則、コーディングスタイル、推奨パターン、ツールの利用方法など、実践的な規約を管理します。

1. 全てのテストに共通する原則

個別のテスト規定を参照する前に、全てのテストケースで遵守すべき、以下の基本的な原則を共有します。

  • 独立性 (Independent):
    • 各テストケースは、他のテストケースから完全に独立している必要があります。実行順序に依存したり、他のテストの結果に影響を与えたりしてはいけません。
  • 決定論的 (Deterministic):
    • テストは、いつ、誰が、何度実行しても、同じ結果（成功または失敗）にならなければなりません。外部環境（現在時刻、ネットワークの状態など）に依存するテストは、その影響を制御下に置く必要があります。
  • 可読性 (Readable):
    • テストコードは、アプリケーションコードと同様に、明確で読みやすいものであるべきです。テストが「何を」「どのような条件で」検証しているのかが一目で分かるように記述します。

AAAパターンの推奨

テストケースの構造は、Arrange（準備）- Act（実行）- Assert（検証）の3つのフェーズに明確に分ける「AAAパターン」で記述することを強く推奨します。これにより、テストの意図が非常に分かりやすくなります。

// Arrange: テスト対象のオブジェクトやデータを準備する
var calculator = new Calculator();
var x = 10;
var y = 20;

    // Act: テスト対象のメソッドを実行する
    var result = calculator.Add(x, y);

    // Assert: 実行結果が期待通りであることを検証する
    Assert.Equal(30, result);

2. 各テストケース規定一覧

プロジェクトで使用するテストの種類に応じて、以下の各規定を参照し、準拠してください。

  • 2.1 単体テスト規定

    • クラスやメソッドといった、最小単位のコンポーネントを検証するためのテストの書き方を定めます。

  • 2.2 結合テスト規定

    • データベースや外部APIなど、複数のコンポーネントを連携させた状態を検証するためのテストの書き方を定めます。

  • 2.3 E2Eテスト規定 (プロジェクトに応じて作成)

    • ユーザーの視点でシステム全体を通したシナリオを検証するためのテスト（UIテストなど）の書き方を定めます。

  • 2.4 パフォーマンステスト規定 (プロジェクトに応じて作成)

    • システムの性能（応答時間、スループットなど）を測定するためのテストの書き方を定めます。