テストデータ管理：スケールでテストデータを扱う方法
Yunhao Jiao
テストデータは、テストの不安定性を引き起こす見落とされがちな原因のひとつです。古くなったデータによって失敗するテスト、共有状態を通じて互いに干渉し合うテスト、本番データに依存しているために再現できないテスト——これらはすべてテストデータの問題であり、非常によく見られる現象です。
適切なテストデータ管理こそが、チームが信頼するテストスイートと、チームが迂回してしまうテストスイートを分ける要因です。
テストデータ管理とは？
テストデータ管理（TDM）とは、自動テストが使用するデータの作成・維持・管理を行うプラクティスです。テストデータの作成方法、テスト間でのデータの分離方法、クリーンアップの方法、そしてアプリケーションのデータモデルが進化するにつれてデータをどのように同期させるかを対象としています。
テストデータ管理が不十分な場合、以下のような問題が現れます：
- 単体では通過するが、フルスイートで失敗するテスト（共有状態の汚染）
- 特定のデータベース内容がある場合のみ通過し、クリーンな環境では失敗するテスト
- 現在は代表性を持たなくなった本番データに基づいて作成されたテスト
- 複雑なシードデータを必要とするため、セットアップに長時間かかるテスト
- 実際には非決定的なデータ依存性があるため、「不安定（flaky）」とマークされたテスト
テストデータの戦略
1. ファクトリーベースのテストデータ
ユニットテストと統合テストにおいて、最も柔軟でメンテナンスしやすいアプローチです。ファクトリー関数が合理的なデフォルト値を持つ最小限の有効なオブジェクトを作成し、テストは自身が関心を持つフィールドのみをオーバーライドします：
ファクトリーはテストをデータ構造の詳細から切り離します。Userに必須フィールドを追加した場合、ユーザーを作成するすべてのテストではなく、ファクトリーを一度だけ更新すれば済みます。
Faker.js（JavaScript）やFactory Boy（Python）などのライブラリは、スケールでリアルなテストデータを生成するためのユーティリティを提供しています。
2. データベースシーディング
テスト実行前にデータが存在している必要がある統合テストやE2Eテストでは、データベースシーディングによって既知の開始状態を作成します。シードは以下のように分類できます：
最小シード：特定のテストやテストスイートに必要なデータのみ。作成が速く、把握しやすく、テスト間の結合を減らします。
シナリオシード：特定のアプリケーション状態を表すリアルなデータセット（例：「5件の注文があり、そのうち2件が保留中のユーザー」）。現実的なコンテキストでの動作を検証する必要があるテストに有効です。
シードはコードと並んでバージョン管理され、データモデルが変更された際に更新されるべきです。
3. 分離のためのデータベーストランザクション
データベースへの書き込みを行うテストへのクリーンなアプローチ：各テストをデータベーストランザクションでラップし、終了時にロールバックします。テストはリアルなデータベース書き込みを行い、それはトランザクション内で参照可能ですが、ロールバックによりデータが永続化されません。
これにより、クリーンアップロジック不要・最小限のオーバーヘッドで完全な分離が実現します。ユニットテストや統合テストには有効ですが、独自のデータベース接続を管理するリアルサーバーに対して実行するE2Eテストには適用できません。
4. 分離されたテストデータベース
E2Eテストでは、各テスト実行前に既知の状態にリセットされる専用テストデータベースを使用するアプローチが最も信頼性が高いです。TestSpriteはまさにこれを実現する分離されたクラウドサンドボックスを使用しており、各テスト実行はクリーンで既知の状態から開始するため、テストの実行順序への依存や共有状態の汚染を防ぎます。
5. 合成データの生成
パフォーマンステストやスケールテストには、手動で作成するよりも大量のデータが必要です。合成データ生成ツールは、プログラムによって大量のリアルなテストデータを作成します。Faker（JavaScript）、PythonのFaker、Mockarooなどの専門ツールは、設定可能なリアルなデータを大量に生成します。
テストにおける機密データ
テストデータ管理における重要な注意点：テスト環境では実際のユーザーデータを絶対に使用しないでください。プライバシー規制（GDPR、CCPA）への対応はもちろん、テスト環境に本番データを持ち込むことはセキュリティリスクやデータ品質上の問題を引き起こします。
データマスキングは本番データをテスト用に変換する手法です。実際のメールアドレスは masked-abc123@test.com に、実際の氏名は「山田 T.」のように、実際の電話番号は生成された有効な番号に置き換えられます。データの構造や量はリアルなまま保たれ、内容のみが匿名化されます。
ステージング環境で本番データのコピーを使用する場合は、データが非本番環境に到達する前に、コピーのパイプライン内でデータマスキングを実施してください。
AI生成コードのためのテストデータ管理
AIコーディングツールを活用するチームには、テストデータに関する固有の課題があります。AIコーディングエージェントは、開発環境では成立するものの本番環境では当てはまらない、データに関する暗黙の前提を含むコードを頻繁に生成します。
例：
- ユーザーには必ずプロフィール写真があると仮定する
- 配列が空になることはないと仮定する
- オプションフィールドには常に値が存在すると仮定する
- タイムスタンプが特定のタイムゾーンであると仮定する
空の配列、null のオプションフィールド、欠損したリレーションシップなどのエッジケースを含む、網羅的なテストデータカバレッジを持つテストは、こうした前提が問題として顕在化する前に検出します。TestSprite のエージェント型テストは、標準カバレッジの一環としてこれらのエッジケースを含むテストケースを自動生成します。
CI/CD におけるテストデータ
CI/CD のすべてのテスト実行において、以下を徹底してください。
- 既知のクリーンなデータ状態（シードまたはリセット済み）から開始する
- ファクトリーまたは最小限のシードを使用して、テスト固有のデータを必要に応じて作成する
- すべてのデータ変更をクリーンアップまたはロールバックする
- 並列テスト実行間でデータ状態を共有しない
TestSprite のクラウドサンドボックス実行は、上記の 1・3・4 を自動的に処理します。テスト実行は分離され、クリーンな状態から開始し、後続の実行に影響する状態を残しません。
TestSprite で分離された信頼性の高いテストデータを構築する →