Bruno モックサーバーある？代替案とおすすめ

Brunoは軽量でGitネイティブなオープンソースのAPIクライアントであり、その設計により高速でバージョン管理が容易になっています。しかし、チームがすぐに直面するギャップがあります。それは、まだ存在しないエンドポイントをモックする方法がないことです。Brunoのモックサーバーの代替品を探している方のために、このガイドではなぜそのギャップが存在するのか、人々が使用する回避策、そしてOpenAPI仕様から直接モックサーバーを生成する方法を説明します。

まず結論から言うと、Brunoには組み込みのモックサーバーはありません。リクエストを送信したりテストを書いたりすることはできますが、サンプル応答を返す偽のエンドポイントを立ち上げることはできません。モックを行うには、外部ツールを利用するか、自分でサーバーを手作りする必要があります。

なぜモックサーバーが必要なのか

モックサーバーは、まだ構築されていない、安定していない、またはオンデマンドでトリガーするのが難しいエンドポイントに対して、現実的な応答を返します。これにより、いくつかのことが可能になります。

• 並行開発。バックエンドがまだ開発中の間、フロントエンドチームとモバイルチームは契約に基づいて構築を進めることができます。誰も待つ必要はありません。
• エラーパスのテスト。実際のAPIでは、必要なときに429や503を返すことはめったにありません。モックを使えば、任意のステータス、ヘッダー、または不正な形式のボディをコマンドで返すことができます。
• デモとプロトタイプ。ライブバックエンド、データベース、認証情報なしで動作するフローを示すことができます。
• 安定したCI。ステージングサーバーがダウンしたりレート制限されたりしても、モックにヒットするテストは壊れません。

ここでは、本番環境で発生するのを待つのではなく、意図的にテストするのにモックが役立つ失敗シナリオを示します。

Brunoにはモックサーバーがありますか？

いいえ、ありません。Brunoは、リクエストの送信、コレクションをプレーンファイルとして整理すること、およびアサーションの実行に焦点を当てています。ネイティブなモックサーバーはなく、保存されたリクエストをライブスタブに変える設定もありません。これは意図的なスコープの選択であり、見落としではありませんが、モックがツールの外で行われることを意味します。

実際には、Brunoユーザーは2つの方法でこのギャップを埋めています。

1. 外部モックツール。Mockoon、WireMock、Prism、json-serverなどの別のサービスを立ち上げ、そこで応答を定義し、BrunoをそのURLに向けます。2つのツール、2つの真実の源です。
2. 手作りのサーバー。あらかじめ用意されたJSONを返す小さなExpress、Flask、またはFastAPIアプリを作成します。1つのエンドポイントには素早いですが、APIが成長するにつれて保守が面倒になります。

どちらも機能します。どちらもコレクションの外に存在する可動部品を追加します。

ボルトオンモックのコスト

Brunoに別のモックレイヤーを組み合わせることは可能ですが、そのコストは時間とともに現れます。

• ズレ。あなたの仕様、Brunoのリクエスト、モックの定義は3つの場所に存在します。エンドポイントを変更すると、その3つすべてを更新するか、1つが静かに古くなります。
• セットアップコスト。新しいチームメイトは全員、ローカルで何かを実行する前にモックツールをインストールして設定する必要があります。
• 手動での応答作成。手作りのサーバーでは、すべてのフィールドとすべてのステータスコードに対して、手動でサンプルペイロードを作成する必要があります。
• 現実的でないデータ。静的スタブは毎回同じ"name": "string"を返すため、多様な入力でしか現れないバグを隠してしまいます。

これらはどれも致命的ではありません。しかし、APIが成長するにつれて摩擦が増大します。これらのギャップがどこで蓄積されるかの詳細については、当社のBrunoの代替オールインワンAPIプラットフォームの内訳を参照してください。

代わりにOpenAPI仕様からモックサーバーを生成する

よりクリーンな方法は、既に管理している契約からモックを派生させることです。Apidogはこれを実現します。OpenAPI仕様をインポートまたは作成するだけで、設計、テスト、ドキュメントに使用するのと同じ定義から、機能するモックサーバーを生成します。3つではなく、1つの真実の源です。

いくつかの点で、これはボルトオンツールとは異なります。

• 仕様からのスマートモック。Apidogはフィールド名とタイプを読み取り、もっともらしいデータを返します。そのため、emailフィールドはメールアドレスのように見え、created_atフィールドは日付のように見えます。ルールを記述する必要はありません。
• 動的な応答。応答はリクエストごとにスキーマから生成されるため、1つの固定された例ではなく、多様なデータが得られます。特定のケースが必要な場合は、条件付きルールを重ねることができます。
• ノーコード設定。別のサーバーを記述したりホストしたりする必要はありません。仕様でエンドポイントを定義すれば、モックURLは準備完了です。
• 同期を維持。仕様を更新すると、同じ定義を共有しているため、モックもそれに合わせて更新されます。

モック、リクエストライブラリ、ドキュメントが同じプロジェクトから生成されるため、別の場所で整合性を保つ必要はありません。ワークフローがGit中心である場合、仕様は差分比較可能でレビュー可能であり、これはGitネイティブAPIワークフローと相性が良いです。モックがどのように役立つかの詳細については、APIモックのユースケースを参照してください。

クイックハウツー：仕様からモックURLへ

既存の仕様からモックを立ち上げる簡単な方法は次のとおりです。

1. 仕様をインポートする。OpenAPI（またはSwagger）ファイルをインポートするか、Apidogに仕様のURLを指示します。既存のエンドポイントとスキーマはそのまま取り込まれます。
2. エンドポイントを開く。インポートされた各エンドポイントにはすでにスキーマがあるため、モックは必要なものをすべて持っています。
3. モックURLを取得する。Apidogは、ローカルおよびクラウドのモックエンドポイントを自動的に公開します。デプロイするサーバーはありません。
4. リクエストを送信する。モックURLにヒットすると、スキーマに準拠したJSONが仕様から生成されて返されます。
5. 応答を調整する（オプション）。特定のパスをテストする必要がある場合（例：429）、特定のステータスコードやエッジケースのルールを追加します。

フロントエンド、モバイルビルド、またはテストスイートをモックURLに向け、バックエンドが追いつく間も開発を進められます。

回避策で十分な場合

公平に見て、常に仕様駆動型のモックが必要なわけではありません。次のような場合は、Brunoと軽量の外部ツールを使い続けるのが良いでしょう。

• 簡単なローカルテストのために、1つか2つのエンドポイントをスタブするだけでよい場合。
• チームがBrunoのファイルベースのコレクションの管理に満足しており、ツールを切り替えたくない場合。
• 多様なデータや多くのエラーパスをテストしないため、静的スタブで十分な場合。
• すでにMockoon、WireMock、またはPrismを実行しており、追加の真実の源が開発を遅らせていない場合。

トレードオフは現実的です。軽量なパスはBrunoのシンプルさを維持しますが、モックを個別に管理する必要があります。仕様駆動型のパスは、より広範なプラットフォームを採用するコストでそのズレを解消します。APIの成長度合いに基づいて選択してください。

FAQ

Brunoには組み込みのモックサーバーがありますか？

いいえ。Brunoはリクエストの送信とテストの実行のためのAPIクライアントです。ネイティブなモックサーバーはないため、エンドポイントをモックするには外部ツールを使用するか、独自のスタブサーバーを作成し、Brunoをそこに向けて使用します。

Brunoスタイルのワークフローにモックを追加する最も簡単な方法は何ですか？

モックを個別に定義するのではなく、OpenAPI仕様からモックを生成します。Apidogのようなツールは仕様を読み取り、すぐに使えるモックURLを生成するため、モック定義を別の場所で管理するのではなく、設計、モック、テスト、ドキュメント全体で1つの真実の源を維持できます。

Brunoを使い続けながら、モックサーバーを併用できますか？

はい。Mockoon、WireMock、Prismなどの外部モックツールを実行し、そこで応答を定義し、BrunoをそのURLに向けます。これは機能しますが、仕様、リクエスト、モックデータが別々の場所に存在し、ズレが生じる可能性があるため、チームが統合する主な理由となります。

もし別個のモックレイヤーの維持が、それがもたらす節約よりもコストがかかるようになったと感じるなら、仕様駆動型モックを試す価値があります。ApidogにOpenAPIファイルをインポートすれば、数分で機能するモックURLが手に入り、追加のサーバーをホストする必要はありません。