開発や検証のためにDBへseedを入れるときは、本番dataをコピーする前に、検証したい状態を少数の架空recordで表現します。正常な一件だけでなく、空欄、重複、権限違い、境界値、関連recordの有無を作り、どの条件を再現したdataかを追えるようにします。
本稿は検証用seedの設計です。DB接続、migration、seed投入、reset、削除は行っていません。Prisma ORM v7を一つの仕様例として使いますが、他バージョンやORMへ同じ実行条件を適用しません。
目次
seedが必要な検証条件から設計する
画面を埋めるためのdataと、失敗を検出するdataを分けます。どのroleがどの状態を読めるか、計算に何の値が必要か、外部連携を起動させるかを一覧にします。data量を増やすことだけを代表性とは呼びません。
表は横にスクロールできます
| Case IDの例 | 作る状態 | 合格条件の例 |
|---|---|---|
| S-01 | ownerと通常record | ownerが必要な操作をできる |
| S-02 | 別ownerのrecord | 権限外の操作を拒否 |
| S-03 | nullable fieldが空 | 欠損を0等と誤認しない |
| S-04 | 同じ業務key候補 | unique・曖昧さを正しく扱う |
| S-05 | 境界の日付・金額 | 対象期間や丸めを確認 |
氏名やmailを置き換えただけで、本番由来のrecordを匿名化できたとは判断しません。自由記述、稀な属性、ファイル、画像、logにも識別情報が残る場合があります。代表条件を架空dataから再構成できるなら、原本の複製を避けます。
接続先と、外部副作用を先に隔離する
seedの実行先host、project、DB名、schema、roleを明示します。環境変数名がdevelopmentでも、実値が本番を指していないかを安全な確認手段で照合します。接続文字列やpasswordをlogへ出す必要はありません。
通知、webhook、定期job、決済、外部検索indexへの反映は、seedがきっかけでも起き得ます。検証用の外部接続やfakeに分け、実顧客への送信や本番台帳更新へ進まない条件を確認します。DBだけを別にして、実serviceのcredentialを同じまま使う構成にしません。
schemaと参照関係を合わせる
必要なmigration バージョン、必須field、foreign key、unique、enum、defaultを確認します。子recordだけを追加して関係が壊れたfixtureを、正常dataとして扱わないようにします。不整合を試したいcaseは、意図したnegative caseとして分けます。
Prisma v7のseeding資料（新しいタブで開く）は、seed commandを設定し、明示的なdb seedで実行する方式を案内しています。v7ではmigrate dev/reset時の自動seedがなくなったと説明されるため、migrationが通っただけで必要dataも入ったと思い込まないようにします。
この製品例は、seedやresetを今実行する指示ではありません。使用ORM/versionで、何を実行するとどの接続先へ何を書き込むかを確認し、resetをdata投入の省略手段にしないことが重要です。
安定したIDと、再実行の意味を決める
caseとrecordを結び付ける安定IDを持たせ、生成の乱数や時点に依存するなら、そのseed値と基準日時を記録します。今日の日付だけを使うfixtureは、翌月に違う状態へ変わるため、固定時刻の検証と現在時刻依存の検証を分けます。
表は横にスクロールできます
| 実行方式 | 決めること | 残る問題 |
|---|---|---|
| 毎回空の検証DB | 作成と破棄の対象 | 実行先の誤指定 |
| 再実行可能な投入 | case ID・unique key | 二重の子record生成 |
| 一部だけ更新 | 更新対象と保持field | 手動検証dataの上書き |
| case別cleanup | 作成したIDと依存順序 | 共有dataの巻込み |
upsertを使っても、nested createや別の副作用が繰り返されない保証にはなりません。再実行後に件数、関連、状態が同じ意図へ収束するかを確認します。cleanupも全table削除ではなく、今回作った検証dataの範囲を識別できるようにします。
AIが作った値を、期待値と同じ役にしない
AIにはcase案や架空の説明文を作らせられますが、検証対象のAIへ正解判定まで丸ごと任せると、同じ誤りを見逃す可能性があります。期待する計算値、許可・拒否、必須field、保留条件を人が先に固定します。
形式に合うmail、通貨、日付でも、業務上の関係が正しいとは限りません。明細合計と総額、親子関係、状態遷移、権限を別に確認します。架空の個人や会社を、実在確認済みの取引先と見せないようにします。
投入前後を照合して、壊れたseedを切り分ける
許可された検証で、投入前の件数、対象case、schema、投入後の一意ID・関係を比較します。途中失敗したら、確定済みrecordと未投入を分けます。再実行でunique violationが出たからといって、全constraintを外して通す対応にはしません。
成功の判断はcommand終了だけでなく、各caseが予定した状態になり、必要な画面・APIの検証に使えることです。失敗時は今回作成したdataと差分を特定して戻し、元からあるWIPや共有fixtureを保持します。
完了記録には、fixture バージョン、作成caseとID、接続先の確認方法、schema、再実行条件、cleanup対象、未確認の副作用を残します。本番を使わずに、次の担当者が同じ失敗条件を再現できる状態がseedの目的です。