DEV Community

Cover image for リアルなAPIテストデータの作り方
Akira
Akira

Posted on • Originally published at apidog.com

リアルなAPIテストデータの作り方

すべてのAPIテストには、実行するためのデータが必要です。ログインテストにはユーザー、チェックアウトテストには注文・住所・支払い記録、検索テストにはページネーションを検証できるだけの大量データが必要です。手作業で入力したデータは時間がかかるうえ、実際のバグを見つけるには整いすぎています。

今すぐApidogを試す

テストデータジェネレーターは、この問題を解決します。要求に応じて現実的で多様なレコードを生成し、実運用データで起こり得るエッジケースをテストに含められます。この記事では、テストデータジェネレーターの基本、主な種類、そして別ツールを追加せずにApidog内でテストデータを生成する方法を実装寄りに整理します。

APIレスポンスのモックから確認したい場合は、先にモックAPIとは何かを読んでから、データ生成に戻ると理解しやすくなります。

テストデータジェネレーターとは?

テストデータジェネレーターは、実際の運用データに近い合成レコードを作成するツールまたはライブラリです。

たとえば、次のような固定データを何度も使う代わりに、

{
  "name": "test",
  "email": "test@test.com"
}
Enter fullscreen mode Exit fullscreen mode

「名前」「有効なメールアドレス」「10〜500の価格」のように必要な形式を指定すると、ジェネレーターがそれらしい値を生成します。

良いテストデータには、次の3つの条件があります。

  • 現実的:名前は名前らしく、メールアドレスは検証を通過し、日付は妥当な範囲に収まる
  • 多様性がある:同じレコードばかりにならず、境界値や分岐条件を踏める
  • 安全:実際の顧客データやPIIをテスト環境・リポジトリに持ち込まない

目的は「きれいなデータ」を作ることではありません。目的は、空文字、Unicode名、巨大な数値、期限切れの日付など、手作業のフィクスチャでは見落としがちな入力をテストに含めることです。

APIテストで現実的なテストデータが重要な理由

APIは入力に応じて分岐します。

  • 不正なメールアドレスを拒否する
  • 範囲外の数値をエラーにする
  • オプションフィールドの有無で処理を変える
  • ステータス値ごとにレスポンスを変える

すべてのテストが次のようなハッピーパスだけなら、検証できる範囲は限定的です。

John Doe / john@example.com / quantity: 1
Enter fullscreen mode Exit fullscreen mode

生成データを使うと、次のようなテストを実行しやすくなります。

  1. 大量データのテスト

    5,000件の商品を生成し、ページネーション、ソート、フィルタリングを検証する。

  2. 境界値のテスト

    price = 0quantity = -1nameが256文字など、検証ロジックを明示的に踏む。

  3. データ駆動型テスト

    CSVまたはJSONの入力テーブルを1つのテストに渡し、各行に対して同じアサーションを実行する。

特に3つ目は、テストデータジェネレーターとAPIテストツールを組み合わせると効果が大きい領域です。

テストデータジェネレーターの主なタイプ

テストデータジェネレーターは、大きく4種類に分けられます。チームによっては複数を併用します。

1. コードライブラリ

Faker.jsやPython版Fakerのようなライブラリは、コードからテストデータを生成します。

JavaScriptでは、たとえば次のように使えます。

import { faker } from '@faker-js/faker';

const user = {
  id: faker.string.uuid(),
  name: faker.person.fullName(),
  email: faker.internet.email(),
  price: faker.commerce.price({ min: 10, max: 500 })
};

console.log(user);
Enter fullscreen mode Exit fullscreen mode

メリットは、スクリプト化しやすく、シードを使えば再現性も確保しやすいことです。

一方で、生成ロジックをコードとして保守する必要があります。JavaScriptで使う場合は、Faker.jsとApidogでの使用方法に関する詳細な解説も参考になります。

2. スタンドアロンおよびオンラインジェネレーター

Mockarooのようなツールでは、Web UIで列を定義し、CSV、JSON、SQLなどでエクスポートできます。

向いている用途は次のとおりです。

  • 一度だけ使うシードファイルを作る
  • ローカル検証用のCSVをすぐに用意する
  • 非エンジニアもUIでデータを作れるようにする

欠点は、生成結果が静的なファイルになりやすいことです。スキーマが変わるたびにUIへ戻り、再生成する必要があります。

3. スキーマベースのジェネレーター

OpenAPI仕様やJSON Schemaがある場合、スキーマベースのジェネレーターを使うと、型や制約に沿ったデータを自動生成できます。

たとえば、次のようなスキーマがある場合、

{
  "type": "object",
  "properties": {
    "email": {
      "type": "string",
      "format": "email"
    },
    "age": {
      "type": "integer",
      "minimum": 18,
      "maximum": 99
    }
  },
  "required": ["email", "age"]
}
Enter fullscreen mode Exit fullscreen mode

ジェネレーターは、emailにはメール形式の文字列、ageには18〜99の整数を生成できます。

OpenAPIベースのフローは、OpenAPIスキーマからモックデータを生成する方法で確認できます。JSON Schema標準では、型、形式、範囲などを機械可読な形で定義できます。

4. AIベースのジェネレーター

AIベースのジェネレーターは、文脈を持ったデータを作るのに向いています。

例:

  • 現実的なサポートチケット
  • もっともらしい商品説明
  • 複数フィールド間で矛盾しないユーザープロファイル
  • 業務ドメインに合った注文履歴

単なるランダム値ではなく、「データ全体として意味が通る」ことが重要な場合に有効です。実例はClaude Codeを使用してモックデータを生成するで紹介されています。

Apidogでテストデータを生成する方法

ApidogでAPIを設計・テストしている場合、テストデータ生成はワークフローの中に組み込めます。別のジェネレーターでJSONを作ってコピーする必要はありません。

主に次の3つの場所で使えます。

1. フィールドルールによるスマートモック

Apidogでエンドポイントをモックすると、フィールド名と型に基づいて、それらしい値を自動生成できます。

例:

  • email → 有効なメールアドレス
  • createdAt → 日付
  • price → 数値
  • phone → 電話番号形式の値

必要に応じて、フィールドごとにFakerスタイルのルールを指定し、出力を制御できます。Apidogをダウンロードすると、定義済みエンドポイントから現実的なモックレスポンスを返せます。db.jsonのような手動メンテナンス用ファイルを別に用意する必要はありません。

Apidogで定義されたJSONスキーマと、自動生成されたモックデータを示すスクリーンショット。フィールドにはメールアドレス、電話番号、日付など、それらしい値が含まれている。

2. AI生成テストデータ

Apidogでは、エンドポイントのスキーマをもとにテストレコードのバッチを生成できます。

すべてのフィールドに手動でルールを書く代わりに、スキーマから多様なデータセットを生成し、テストやモックで利用できます。

ApidogのUIでAIがテストデータを生成しているアニメーションGIF。AIがJSONスキーマに基づいてデータを生成する様子が示されている。

3. データ駆動型テスト

テストステップにCSVまたはJSONデータセットを添付すると、Apidogは各行を変数として差し込みながらテストを繰り返し実行できます。

イメージとしては、次のようなCSVを用意します。

email,password,expectedStatus
valid@example.com,correct-password,200
invalid-email,correct-password,400
valid@example.com,wrong-password,401
Enter fullscreen mode Exit fullscreen mode

テスト側では、リクエストボディやアサーションに変数を使います。

{
  "email": "{{email}}",
  "password": "{{password}}"
}
Enter fullscreen mode Exit fullscreen mode

これにより、1つのテスト定義で複数の入力パターンを検証できます。

設定方法はCSVおよびJSONからのパラメーター化APIテストの実行方法で説明されています。ツール選定の観点では、データ駆動型APIテストにどのツールを使用するかも参考になります。CIで実行する場合は、同じデータセットをApidog CLIでのデータ駆動型テストから利用できます。

ステップバイステップ:エンドポイントのテストデータを生成する

Apidogでテストデータを使う基本手順は次のとおりです。

  1. Apidogでプロジェクトを開く
  2. テストデータが必要なエンドポイントを選択する
  3. レスポンススキーマを定義する、またはOpenAPIファイルからインポートする
  4. フィールド名、型、制約を確認する
  5. モックを有効化する
  6. 生成されたレスポンスを確認する
  7. 必要に応じてフィールドごとのモックルールを追加する
  8. テスト実行用にCSVまたはJSONデータセットを作る
  9. データセットをテストステップに添付する
  10. 各行に対してリクエストとアサーションを実行する

たとえば、statusフィールドを限定したい場合は、次のような値セットを使います。

["active", "pending", "closed"]
Enter fullscreen mode Exit fullscreen mode

テストでは、正常系だけでなく異常系も同じデータセットに含めます。

[
  {
    "email": "user@example.com",
    "quantity": 1,
    "expectedStatus": 200
  },
  {
    "email": "invalid-email",
    "quantity": 1,
    "expectedStatus": 400
  },
  {
    "email": "user@example.com",
    "quantity": -1,
    "expectedStatus": 400
  }
]
Enter fullscreen mode Exit fullscreen mode

これで、開発用の現実的なモックレスポンスと、テスト用の反復可能な入力テーブルを同じ場所で管理できます。

テストデータジェネレーターの選び方

必要な場合… 使用する 理由
JS/Pythonで完全に制御したい Fakerライブラリ 柔軟、スクリプト可能、シードで再現可能
すぐに静的なシードファイルを作りたい Mockarooまたは類似ツール コード不要、エクスポートして使える
API契約に一致するデータが必要 スキーマベース(OpenAPI/JSON Schema) 仕様と同期しやすい
文脈に合った自然なレコードが必要 AIジェネレーター 複数フィールド間で一貫性を持たせやすい
モックとテストに生成データを組み込みたい Apidog モック、生成、実行を1つのツールで扱える

唯一の正解はありません。スクリプト中心のチームはFakerを使いやすく、ApidogでAPIを設計・テストしているチームは、ワークスペースを離れずに生成、モック、データ駆動型実行をまとめて扱えます。

APIテストデータのベストプラクティス

1. 再現性のためにシードを使う

ランダムデータでテストが失敗した場合、同じデータを再生成できなければデバッグが難しくなります。再現したいテストでは固定シードを使います。

import { faker } from '@faker-js/faker';

faker.seed(123);

console.log(faker.person.fullName());
console.log(faker.internet.email());
Enter fullscreen mode Exit fullscreen mode

2. 正常データだけでなく不正データも含める

APIテストでは、有効な入力だけでは不十分です。

含めるべき例:

  • 空文字
  • null
  • 想定外の型
  • 負の数
  • 上限を超える文字列
  • 期限切れトークン
  • 不正な日付形式
  • 必須フィールドなし

3. データとスキーマを同期させる

API契約が変わったら、テストデータも更新します。スキーマベースの生成を使うと、フィールド追加・型変更・制約変更に追従しやすくなります。

4. 実際のPIIを使わない

テストデータには、実在する顧客名、メールアドレス、電話番号、住所などを使わないでください。合成データを使うことで、プライバシーリスクとリポジトリへの漏洩リスクを避けられます。

5. テスト目的に合わせてデータ量を変える

必要なデータ量はテストの種類で変わります。

  • 単一のバリデーション確認:数件で十分
  • ページネーション検証:数百〜数千件
  • パフォーマンステスト:本番に近い件数
  • 境界値テスト:少数の明示的な値

FAQ

テストデータジェネレーターとモックサーバーの違いは何ですか?

テストデータジェネレーターはデータを作成します。モックサーバーは、そのデータをHTTPレスポンスとして返します。

多くの場合、両方が必要です。Apidogでは、生成されたデータをモックレスポンスとして返せるため、データ生成とモックを同じワークフローで扱えます。

OpenAPI仕様からテストデータを生成できますか?

はい。スキーマベースのツールは、OpenAPI仕様の型や制約を読み取り、それに沿ったデータを生成できます。詳しくはOpenAPIスキーマからモックデータを生成するを参照してください。

生成されたテストデータをリポジトリにコミットしても安全ですか?

合成データであり、実際の個人情報を含まない場合は安全です。ただし、運用データのエクスポートをコミットするのは避けてください。

生成された多くの入力に対して1つのテストを実行するにはどうすればよいですか?

データ駆動型テストを使います。CSVまたはJSONデータセットをテストに添付し、各行の値を変数としてリクエストやアサーションに差し込みます。設定方法はパラメーター化されたテストガイドで確認できます。

テストデータを使うために偽のサーバーを立ち上げる必要がありますか?

必ずしも必要ではありません。フラットファイルをもとに使い捨てのREST APIを立ち上げたい場合は、json-serverとJSONPlaceholderに関するガイドが参考になります。

スキーマを認識し、チームで共有できるモックが必要な場合は、Apidogの内蔵モックを使うと管理しやすくなります。

要するに

テストデータジェネレーターは、手作業でレコードを作る手間を減らし、APIテストに必要な現実的・多様・安全なデータを生成します。

  • コードで細かく制御したい場合はFaker
  • API契約と同期したい場合はOpenAPI/JSON Schemaベースの生成
  • 文脈のあるレコードが必要な場合はAIジェネレーター
  • モック、生成、データ駆動型テストをまとめたい場合はApidog

すでにApidogでAPIをテストしているなら、生成データをそのままモックやテスト実行に流用できます。Apidogをダウンロードし、エンドポイントを定義すれば、最初のリクエストから現実的なテストデータを確認できます。

Top comments (0)