Oracle-to-PostgreSQL マイグレーション向けの統合テストの作成

単一ターゲットプロジェクトのデータアクセスアーティファクト向けの統合テストケースを生成します。テストは Oracle または PostgreSQL に対して実行する際の動作一貫性を検証します。

前提条件

• テストプロジェクトが既に存在し、コンパイルできること（別途スキャフォールド済み）。
• テストを記述する前に、既存のベーステストクラスとシード管理の規約を読むこと。

ワークフロー

テスト作成:
- [ ] ステップ 1: テストプロジェクトの規約を把握する
- [ ] ステップ 2: テスト可能なデータアクセスアーティファクトを特定する
- [ ] ステップ 3: シードデータを作成する
- [ ] ステップ 4: テストケースを記述する
- [ ] ステップ 5: 決定性を確認する

ステップ 1: テストプロジェクトの規約を把握する

ベーステストクラス、シードマネージャー、およびプロジェクトファイルを読んで、継承パターン、トランザクション管理、およびシードファイルの規約を理解する。

ステップ 2: テスト可能なデータアクセスアーティファクトを特定する

ターゲットプロジェクトのみを対象にします。データベースと相互作用するデータアクセスメソッド（リポジトリ、DAO、ストアドプロシージャ呼び出し、クエリビルダー）をリストアップします。

ステップ 3: シードデータを作成する

• 既存プロジェクトのシードファイルの場所と命名規約に従う。
• 可能な限り既存のシードファイルを再利用する。
• TRUNCATE TABLE を使用しない。既存のデータベースデータをそのまま保つ。
• シードデータをコミットしない。テストはロールバックするトランザクション内で実行される。
• シードデータが他のテストと競合しないことを確認する。
• アサーションがシードデータに依存する前に、シードデータを読み込んで検証する。

ステップ 4: テストケースを記述する

• ベーステストクラスから継承して、自動的なトランザクション作成/ロールバック機能を取得する。
• プラットフォーム固有のメッセージではなく、論理的な出力（行、列、カウント、エラータイプ）をアサートする。
• 具体的な期待値をアサートする。シードデータから具体的な値が利用可能な場合、値が単に非 null または空ではないことをアサートしない。
• 存在しないコードパスのテストやコード実行不可能な動作のアサーションを避ける。
• 同じメソッドをターゲットとするテスト全体で冗長なアサーションを避ける。

ステップ 5: 決定性を確認する

非 null 値に対するすべてのアサーションを再検討します。それぞれがシードデータに対して決定的であることを確認します。テストの制御外のデータベース状態に依存するアサーションを修正します。

主要な制約

• Oracle が真実のソース — テストは Oracle の期待される動作をキャプチャします。
• DB に依存しないアサーション — アサーション内にプラットフォーム固有のエラーメッセージまたは構文を含めない。
• Oracle に対してのみシード — テストプロジェクトは後で PostgreSQL にマイグレーションされます。
• 単一プロジェクトにスコープ — ターゲットプロジェクトの外部のアーティファクト向けのテストを作成しない。