mcpField
C
creating-oracle-to-postgres-migration-integration-tests

creating-oracle-to-postgres-migration-integration-tests

github.com/githubテスト・品質40.5k1.8k 回インストール今日更新
リポジトリ

creating-oracle-to-postgres-migration-integration-tests について

.NET の Oracle から PostgreSQL への移行で、単一プロジェクトの統合テストを作成するスキルです。Oracle の動作を基準とし、移行後も維持しやすいアサーションを用います。

主な機能

  1. 01テストプロジェクトの規約確認
  2. 02データベースアクセス処理の特定
  3. 03分離されたシードデータの作成
  4. 04移植可能なアサーションの記述
  5. 05テストの決定性の確認

活用シーン

  1. 01リポジトリや DAO の統合テスト作成
  2. 02ストアドプロシージャ呼び出しやクエリビルダーのテスト
  3. 03移行前の Oracle の動作記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/github/awesome-copilot --skill creating-oracle-to-postgres-migration-integration-tests

インストール後、Claude Code で/creating-oracle-to-postgres-migration-integration-testsを入力して読み込まれたか確認します。

詳細

Oracle から PostgreSQL への移行に向けた統合テストの作成

単一の対象プロジェクトにあるデータアクセス成果物の統合テストケースを生成します。テストは Oracle を対象とし、その動作を基準となる正解として記録します。論理的に移植可能な形で記述するため、書き直すことなく Phase 6 の移行後も利用できますが、この段階では PostgreSQL に対して実行しません。

前提条件

  • テストプロジェクトがすでに作成され、コンパイルできること(スキャフォールドは別途実施)。
  • テストを記述する前に、既存の基本テストクラスとシードマネージャーの規約を確認すること。

ワークフロー

Test Creation:
- [ ] Step 1: Discover the test project conventions
- [ ] Step 2: Identify testable data access artifacts
- [ ] Step 3: Create seed data
- [ ] Step 4: Write test cases
- [ ] Step 5: Review determinism

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

基本テストクラス、シードマネージャー、プロジェクトファイルを読み、継承パターン、トランザクション管理、シードファイルの規約を把握します。

ステップ 2:テスト対象のデータアクセス成果物を特定する

対象プロジェクトだけに範囲を限定します。データベースとやり取りするデータアクセスメソッド(リポジトリ、DAO、ストアドプロシージャの呼び出し元、クエリビルダー)を列挙します。

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

  • 既存プロジェクトのシードファイルの配置場所と命名規約に従います。
  • TRUNCATE TABLE は避け、既存のデータベースデータを保持します。
  • 既存の業務データ行とルックアップ行はすでに存在すると想定し、シナリオに必要な最小限の、衝突しないシードレコードのみを追加します。
  • シードデータをコミットしないでください。テストはロールバックするトランザクション内で実行されます。
  • シードデータが他のテストと競合しないようにします。
  • アサーションがシードデータに依存する場合は、その前にシードデータを読み込み、検証します。
  • シードビルダーとアサーションで使用する、安定したルックアップ ID/コードのために、テスト用の LookupConstants クラスを作成または再利用します。

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

  • 基本テストクラスを継承して、トランザクションの自動作成とロールバックを利用します。
  • 対象範囲内の、データベースにアクセスする各メソッドに対して、少なくとも 1 つの統合テストを用意します(リスクの高い動作分岐には複数のテストを用意します)。
  • プラットフォーム固有のメッセージではなく、論理的な出力(行、列、件数、エラーの種類)を検証します。
  • 具体的な値をシードデータから取得できる場合、値が単に null ではない、または空ではないことだけを検証せず、具体的な期待値を検証します。
  • 存在しないコードパスのテストや、発生し得ない動作の検証は避けます。
  • 同じメソッドを対象とするテスト間で、冗長なアサーションを避けます。
  • テキストパラメーターについて、該当する場合は空文字と NULL/入力なしの両方をテストします。
  • 日時の動作について、書き込んだ値と読み戻した値が一致することを検証するアサーションを含めます。特定のデータベース型構文を想定せず、Oracle の列の精度(たとえば、小数秒のない日時列では秒単位)を使用します。

ステップ 5:決定性を見直す

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

主な制約

  • Phase 3 のみ — これらのテストは Oracle を対象とします。Phase 6 で、または PostgreSQL を対象とするプロジェクトに対して、このスキルを実行しないでください。
  • Oracle を正解の基準とする — テストでは Oracle の期待される動作を記録します。
  • アサーションの移植性 — アサーションではプラットフォーム固有のエラーメッセージや構文を避けます。これにより、Phase 6 でテストプロジェクトを PostgreSQL に移行する際に、アサーションを変更せずに済みます。
  • Oracle のみを対象としたシード — テストプロジェクトは Phase 6 で PostgreSQL に移行されるため、それまではシードデータとインフラストラクチャーを Oracle 向けに維持します。
  • 単一プロジェクトに限定 — 対象プロジェクト外の成果物に対するテストは作成しないでください。
  • 既存データを保持 — 既存の業務データ行やルックアップ行を書き換えたり、消去したりしないでください。

コメント