ApidogとSchemathesisを比較しているなら、まず「どちらを選ぶか」ではなく「CIでどの役割を持たせるか」を分けて考えるのが実装しやすいです。SchemathesisはOpenAPI/GraphQLスキーマから未知のエッジケースを探すプロパティベースのファザーです。一方、ApidogはAPI設計、モック、機能テスト、契約テスト、CI実行をまとめて扱うAPIプラットフォームです。基礎知識はAPIテスト究極ガイド、Schemathesisの詳細はGitHubのドキュメントとソースを参照してください。
要約
Schemathesisは、OpenAPIまたはGraphQLスキーマを入力として受け取り、大量のリクエストを生成してAPIの破綻ポイントを探します。PythonのプロパティベーステストライブラリであるHypothesisをベースにしており、次のような問題を見つけるのに向いています。
- 想定外の入力で発生する500エラー
- スキーマと一致しないレスポンス
- 本来拒否すべき値を受け入れてしまうバリデーション漏れ
ApidogはオールインワンのAPIプラットフォームです。APIを視覚的に設計し、機能テストと契約テストを作成し、CSV/JSONデータでテストを回し、モックを作成し、apidog runでCI/CDに組み込めます。REST、gRPC、WebSocket、SSE、SOAP、GraphQLを1つのワークスペースで扱えます。
実務では、次のように分担すると明確です。
- Schemathesis: スキーマから未知のエッジケースを自動探索する
- Apidog: チームが保守する意図的なテスト、契約テスト、モック、ドキュメント、CI実行を管理する
Schemathesisが得意なこと
Schemathesisはスキーマを契約として読み込み、その契約を破る入力を生成します。OpenAPIの型、必須項目、制約などをもとにリクエストを作成し、レスポンスが仕様と一致するかを検証します。
代表的な検出対象は次のとおりです。
- 手動テストでは考慮しにくい値による500エラー
- レスポンスの型不一致
- 必須フィールドの欠落
- ドキュメントにないフィールドの返却
- 無効なリクエストに対する2xxレスポンス
基本的な実行イメージは次のようになります。
schemathesis run openapi.yaml --url http://localhost:8000
CIでDockerを使う場合は、スキーマファイルとテスト対象URLを渡して実行します。
docker run --rm \
-v "$PWD:/app" \
schemathesis/schemathesis \
run /app/openapi.yaml \
--url http://host.docker.internal:8000
Schemathesisの強みは、個別のテストケースを大量に手書きしなくても、スキーマに基づいて入力空間を探索できることです。失敗を見つけると、Hypothesisの仕組みにより再現に必要な最小ケースへ縮小されるため、デバッグしやすくなります。
また、あるAPIレスポンスの値を次のリクエストに使うような操作の連鎖も扱えるため、単発のエンドポイントだけでなく、より現実的なAPIシーケンスの検証にも利用できます。
ただし、Schemathesisはテストエンジンであり、API設計、モック、ドキュメント、非エンジニア向けUIを提供するツールではありません。既にスキーマが存在し、それをもとにファジングしたい場合に最も効果を発揮します。
Apidogが得意なこと
Apidogは、Schemathesisのようなプロパティベースのファジングツールではありません。Apidogの役割は、API開発ライフサイクル全体を1つの場所で管理し、チームが保守できるテストスイートを作ることです。
Apidogでは次の作業を実行できます。
- OpenAPIベースのエディターでAPI仕様を視覚的に設計する
- 仕様を真のソースとして維持する
- スクリプト不要のアサーションで機能テストを作成する
- 複数ステップのテストシナリオを作成する
- ステップ間でレスポンス値を受け渡す
- 契約テストで実装と仕様のずれを検出する
-
apidog run -dでCSV/JSONを使ったデータ駆動テストを実行する - バックエンド実装前にモックAPIを提供する
- apidog runコマンドでCI/CDに組み込む
- REST、gRPC、WebSocket、SSE、SOAP、GraphQLを同じワークスペースで扱う
たとえば、次のようなケースはApidog側で管理するのが自然です。
- 有効な注文リクエストで
201が返ること - レスポンスに注文IDが含まれること
- 期限切れトークンで
401が返ること - チェックアウトフローで、カート作成ステップのIDを決済ステップへ渡すこと
- CSVの複数行データを使って同じシナリオを繰り返すこと
CIでは次のように実行できます。
apidog run
CSVまたはJSONのデータファイルを使う場合は、次のようにデータ駆動で実行します。
apidog run -d test-data.csv
ここで重要なのは、ApidogのモンキーテストとSchemathesisのプロパティベーステストを混同しないことです。Apidogはランダム入力を投げるモンキーテストをサポートしていますが、これはスキーマの型や制約から戦略的に入力を生成するSchemathesisのプロパティベースファジングとは異なります。
真のプロパティベースファジングが必要ならSchemathesisを使います。チームで保守する機能テスト、契約テスト、モック、ドキュメント、CI実行をまとめたいならApidogを使います。
直接比較
| 機能 | Apidog | Schemathesis |
|---|---|---|
| 主要な役割 | 機能テスト、契約テスト、設計、モック、ドキュメント | スキーマからのプロパティベースファジング |
| テスト作成 | ビジュアル、ノーコードのアサーション、シナリオ | スキーマから自動生成、コード内のプロパティ |
| 入力戦略 | 意図的なケース、CSV/JSONによるデータ駆動 | スキーマの入力空間に基づく生成入力 |
| 未知のエッジケースの発見 | 限定的。ランダムモンキーテストは可能だが、プロパティベースではない | 得意領域 |
| スキーマ/仕様の契約チェック | 契約テストで対応 | 仕様に対してレスポンスを検証 |
| プロトコル | REST、gRPC、WebSocket、SSE、SOAP、GraphQL | OpenAPI REST、GraphQL |
| モック | 組み込み | なし |
| API設計 + ドキュメント | ビジュアルデザイナー、自動ドキュメント | なし |
| CI/CD | apidog run | CLI、Docker、GitHub Actions、pytest |
| インターフェース | デスクトップアプリ、CLI | CLI、Pythonライブラリ |
| 対象者 | 開発者、QA、技術リーダー、フロントエンド、テクニカルライター | Python/CLIに慣れたエンジニア |
この比較から分かるとおり、Apidogは広範なAPI開発ワークフローを扱うツールです。Schemathesisは、スキーマベースの生成テストに特化したツールです。
両方を使う実装パターン
実務では、ApidogとSchemathesisを同じスキーマに接続して使うのが最も分かりやすい構成です。
1. Apidogで意図的なテスト層を作る
まず、ApidogでAPI仕様を管理し、チームがレビューできるテストを作ります。
対象にするのは、ビジネス上重要なシナリオです。
- ログイン成功時にトークンが返る
- 無効な認証情報で
401が返る - 注文作成後、レスポンスの注文IDを取得する
- 取得した注文IDで注文詳細を取得する
- 権限のないユーザーが管理APIを呼ぶと
403になる
このようなテストは、仕様やプロダクト要件に紐づくため、人間が意図を持って管理する必要があります。
CIではブロッキングゲートとして実行します。
name: Apidog API Tests
on:
pull_request:
push:
branches:
- main
jobs:
apidog-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Apidog tests
run: apidog run
データ駆動テストを使う場合は、CSVまたはJSONをリポジトリに置き、CIで渡します。
- name: Run Apidog data-driven tests
run: apidog run -d test-data.csv
2. Schemathesisで生成的なファジング層を作る
次に、同じOpenAPIまたはGraphQLスキーマをSchemathesisに渡します。ここでは、人間が思いつかない入力を探索させることが目的です。
schemathesis run openapi.yaml --url http://localhost:8000
GitHub Actionsでは、Apidogとは別ジョブに分けると運用しやすくなります。
name: Schemathesis Fuzzing
on:
schedule:
- cron: "0 2 * * *"
workflow_dispatch:
jobs:
schemathesis:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Schemathesis
run: pip install schemathesis
- name: Run fuzzing
run: schemathesis run openapi.yaml --url http://localhost:8000
Schemathesisはファジングの性質上、実行時間が長くなったり、初期導入時に多くの問題を検出したりする可能性があります。そのため、最初は夜間ジョブや手動実行に分け、安定してからPRゲートに組み込む方が現実的です。
3. スキーマを共有契約として維持する
ApidogとSchemathesisをつなぐ中心はスキーマです。
- Apidog: 設計、モック、契約テスト、ドキュメントのソースとして使う
- Schemathesis: 入力生成とレスポンス検証のソースとして使う
スキーマが古くなると、どちらのテストも弱くなります。逆に、スキーマの品質を高く保てば、ApidogのテストもSchemathesisのファジングも精度が上がります。
最低限、次の項目はスキーマに明示しておくと効果的です。
- 必須フィールド
- 型
- enum
- 文字列長
- 数値範囲
- nullable
- レスポンスのステータスコード
- エラーレスポンスの形式
- 認証要件
よくある質問
ApidogはSchemathesisの代替品ですか？
完全な代替ではありません。
プロパティベースのファジングが目的なら、Schemathesisを使うべきです。Apidogはスキーマから大量の入力を生成して縮小するプロパティベースファザーではありません。
一方で、API設計、機能テスト、契約テスト、モック、ドキュメント、CI実行を1つのワークフローで管理したいなら、Apidogがカバーする範囲は広くなります。契約テストについてはApidogでの契約テストの仕組みを参照してください。
プロパティベーステストと機能APIテストの違いは何ですか？
機能テストは、既知の入力と期待結果を検証します。
例:
- このペイロードなら
201が返る - このトークンなら
401が返る - レスポンスに
orderIdが含まれる
プロパティベーステストは、多数の生成された入力に対して一般的な性質を検証します。
例:
- APIはどの入力でも500を返すべきではない
- レスポンスは常にスキーマに一致すべき
- 無効な入力は2xxで成功してはいけない
機能テストは「意図した動作」を確認します。プロパティベーステストは「想定外の壊れ方」を探します。役割が違うため、両方を使うのが効果的です。
Apidogはファジングを行いますか？
Apidogにはランダム入力を送信するモンキーテストがあります。ただし、これはSchemathesisが行うプロパティベースファジングとは異なります。
プロパティベースファジングでは、スキーマの型や制約から入力を生成し、失敗したケースを最小化して再現しやすくします。この用途にはSchemathesisが適しています。
Apidogは、意図的なテストケース、データ駆動テスト、契約テスト、モック、API設計、CI実行に向いています。
同じCIパイプラインで両方を実行できますか？
はい。おすすめの分け方は次のとおりです。
- Apidog: PRごとのブロッキングゲート
- Schemathesis: 別ジョブ、夜間ジョブ、または手動実行
Apidogの機能テストと契約テストは決定論的なので、常に通るべき品質ゲートとして扱いやすいです。Schemathesisは探索的な性質が強いため、最初は別ジョブにしてノイズを分離すると導入しやすくなります。
結論
Schemathesisは、OpenAPIまたはGraphQLスキーマから未知のエッジケースを探す強力なプロパティベースファザーです。手書きテストでは見逃しやすい500エラー、スキーマ不一致、バリデーション漏れを検出できます。
Apidogは、その周辺のAPI開発ワークフローを支えるプラットフォームです。視覚的なAPI設計、機能テスト、契約テスト、データ駆動実行、モック、CI/CD、REST/gRPC/WebSocket/SSE/SOAP/GraphQL対応を1つの場所で扱えます。
実装方針はシンプルです。
- Apidogでスキーマ、モック、機能テスト、契約テストを管理する
-
apidog runでCIのブロッキングゲートを作る - Schemathesisで同じスキーマを使ってファジングする
- Schemathesisは別ジョブまたは夜間ジョブから始める
- スキーマを常に最新の共有契約として保つ
意図的で保守可能なAPIテストスイートを作るならApidogをダウンロードし、生成的なファジングにはSchemathesisを使い続けるのが現実的です。Apidogは無料で試すことができ、機能テストをApidogに集約すれば、CI連携は1つのコマンドで開始できます。
Top comments (0)