Akira

Posted on Jun 2 • Originally published at apidog.com

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

Brunoは軽量でGitネイティブなオープンソースAPIクライアントです。高速にリクエストを送信でき、コレクションをバージョン管理しやすい一方で、まだ存在しないエンドポイントをモックする組み込み機能はありません。この記事では、Brunoでモックサーバーが必要になる場面、よくある回避策、OpenAPI仕様からモックサーバーを生成する実装手順を整理します。

今すぐApidogを試す

結論から言うと、Brunoには組み込みのモックサーバーはありません。リクエスト送信やテストの実行はできますが、サンプルレスポンスを返す偽のエンドポイントをBruno単体で立ち上げることはできません。モックが必要な場合は、外部ツールを使うか、独自にスタブサーバーを作成します。

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

モックサーバーは、まだ実装されていない、安定していない、または再現が難しいAPIレスポンスを意図的に返すために使います。

主な用途は次のとおりです。

並行開発：バックエンド実装を待たずに、フロントエンドやモバイルアプリをAPI契約に基づいて実装できる。
エラーパスの検証：429、500、503など、本番APIでは任意のタイミングで発生させにくい状態をテストできる。
デモ・プロトタイプ：DB、認証、ライブバックエンドなしで動作する画面フローを見せられる。
CIの安定化：ステージング環境の停止やレート制限に依存せず、テストを安定して実行できる。

たとえば、次のような失敗シナリオはモックで意図的に再現できます。

シナリオ	モックが返すもの	実APIだけで再現する難しさ
レート制限に達した	`429` + `Retry-After` ヘッダー	バックエンドはオンデマンドでめったにスロットルしない
サーバー停止	`500` / `503`	テストのためだけにステージングを壊せない
応答が遅い	遅延したボディ	実際のレイテンシを安定して再現しづらい
空の結果セット	`200` と `[]`	特定のデータ状態に依存する
不正なペイロード	必須フィールドが欠落したボディ	通常はバックエンドのバリデーションで防がれる

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

ありません。

Brunoは、次の用途にフォーカスしたAPIクライアントです。

HTTPリクエストの送信
コレクションをプレーンファイルとして管理
アサーションによるテスト実行
Gitでの差分管理

一方で、保存済みリクエストをライブスタブに変換するネイティブなモックサーバー機能はありません。これはBrunoのスコープ上の選択であり、モックはBrunoの外側で用意する必要があります。

Brunoユーザーがよく使う回避策は主に2つです。

外部モックツールを使う
- Mockoon
- WireMock
- Prism
- json-server

これらを別サービスとして起動し、Brunoのリクエスト先URLをそのモックサーバーに向けます。

手作りのスタブサーバーを作る
- Express
- Flask
- FastAPI

あらかじめ用意したJSONを返す小さなサーバーを作成します。

たとえばExpressなら、最小構成は次のようになります。

import express from "express";

const app = express();

app.get("/users", (req, res) => {
  res.json([
    {
      id: 1,
      name: "Taro Yamada",
      email: "taro@example.com"
    }
  ]);
});

app.get("/rate-limit", (req, res) => {
  res.set("Retry-After", "60");
  res.status(429).json({
    message: "Too Many Requests"
  });
});

app.listen(3000, () => {
  console.log("Mock server running on http://localhost:3000");
});

Bruno側では、リクエスト先を次のように変更します。

http://localhost:3000/users

この方法はすぐに試せますが、APIが増えると保守が重くなります。

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

Brunoに外部モックレイヤーを組み合わせることは可能です。ただし、APIが成長すると次のようなコストが出てきます。

仕様・Brunoリクエスト・モック定義がズレる
- エンドポイントやレスポンススキーマを変更するたびに、複数箇所を更新する必要があります。
セットアップが増える
- 新しいメンバーはBrunoに加えて、モックツールのインストールや設定も必要になります。
レスポンス作成が手作業になる
- ステータスコードごと、エンドポイントごとにJSONを用意する必要があります。
データが固定化される
- 静的スタブが毎回同じ "name": "string" のような値を返すと、多様な入力でのみ発生するバグを見逃しやすくなります。

これらは致命的な問題ではありません。ただし、APIが増えるほど「別管理のモック」は摩擦になります。Brunoと統合型APIプラットフォームの違いについては、Brunoの代替オールインワンAPIプラットフォームも参考になります。

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

より保守しやすい方法は、既に管理しているOpenAPI仕様からモックを生成することです。

Apidogでは、OpenAPI仕様をインポートまたは作成すると、同じ定義からモックサーバーを生成できます。設計、テスト、ドキュメント、モックを1つのAPI契約に集約できるため、複数の真実の源を管理する必要がありません。

仕様駆動のモックには、次の利点があります。

スキーマからスマートモックを生成
- フィールド名や型に基づいて、もっともらしいデータを返します。
- 例：email はメールアドレス形式、created_at は日時形式の値になる。
動的なレスポンスを返せる
- 固定JSONではなく、スキーマに基づいたバリエーションのあるレスポンスを生成できます。
ノーコードでモックURLを利用できる
- 別途ExpressやFlaskのサーバーを書く必要がありません。
仕様変更と同期しやすい
- OpenAPI定義を更新すれば、同じ定義を参照するモックも更新されます。

モック、リクエスト、ドキュメントが同じプロジェクトから生成されるため、整合性を別々に保つ必要がありません。Git中心のワークフローでは、仕様ファイルを差分確認・レビューできるため、GitネイティブAPIワークフローとも相性が良いです。モックの具体的な利用場面については、APIモックのユースケースも参照してください。

クイックハウツー：仕様からモックURLを作る

既存のOpenAPI仕様からモックを立ち上げる基本手順は次のとおりです。

1. OpenAPI仕様を用意する

既存のOpenAPIまたはSwaggerファイルを使います。

openapi: 3.0.0
info:
  title: User API
  version: 1.0.0
paths:
  /users:
    get:
      summary: List users
      responses:
        "200":
          description: User list
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
                  properties:
                    id:
                      type: integer
                    name:
                      type: string
                    email:
                      type: string
                      format: email

2. Apidogに仕様をインポートする

ApidogでOpenAPIファイルをインポートするか、仕様ファイルのURLを指定します。既存のパス、メソッド、スキーマが取り込まれます。

3. エンドポイントを確認する

インポートされた各エンドポイントには、レスポンススキーマが紐づきます。モックサーバーはこのスキーマを元にレスポンスを生成します。

4. モックURLを取得する

Apidogはローカルまたはクラウドのモックエンドポイントを公開します。別のサーバーをデプロイする必要はありません。

5. アプリやテストからモックURLを呼び出す

フロントエンドやテストコードのAPIベースURLを、モックURLに差し替えます。

const API_BASE_URL = "https://your-mock-url.example.com";

const res = await fetch(`${API_BASE_URL}/users`);
const users = await res.json();

console.log(users);

6. 必要に応じてエラーケースを追加する

たとえばレート制限のハンドリングをテストしたい場合は、429レスポンスを返すケースを追加します。

{
  "message": "Too Many Requests"
}

このように、バックエンドが未実装でもフロントエンド、モバイルアプリ、CIテストを進められます。

回避策で十分な場合

必ずしもすべてのチームに仕様駆動型モックが必要なわけではありません。

次のような場合は、Brunoと軽量な外部ツールの組み合わせでも十分です。

1〜2個のエンドポイントをローカルで一時的にスタブしたいだけ。
チームがBrunoのファイルベースのコレクション管理に満足している。
多様なデータや複数のエラーパスを検証する必要がない。
すでにMockoon、WireMock、Prismを運用していて、ズレが問題になっていない。

判断基準はシンプルです。

小規模・一時的なモック：外部ツールや手作りサーバーで十分。
APIが増えて仕様との同期が重要：OpenAPI仕様からモックを生成する方が保守しやすい。

軽量な方法はBrunoのシンプルさを維持できます。一方で、仕様駆動型の方法は、モック定義のズレを減らせます。APIの規模とチームの運用に合わせて選択してください。

FAQ

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

いいえ。BrunoはAPIリクエストの送信とテスト実行にフォーカスしたクライアントです。ネイティブなモックサーバーはありません。エンドポイントをモックするには、外部ツールを使うか、独自のスタブサーバーを作成してBrunoからそのURLを呼び出します。

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

OpenAPI仕様からモックを生成する方法です。Apidogのようなツールを使うと、仕様を読み取ってすぐに使えるモックURLを生成できます。モック定義を別管理するのではなく、設計、モック、テスト、ドキュメントで1つのAPI契約を共有できます。

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

はい。Mockoon、WireMock、Prismなどの外部モックツールを起動し、Brunoのリクエスト先をそのURLに向ければ利用できます。ただし、仕様、Brunoリクエスト、モックデータが別々の場所に存在するため、変更時にズレが発生しやすくなります。

まとめ

Brunoは軽量でGitネイティブなAPIクライアントですが、組み込みのモックサーバーはありません。小規模な用途なら、MockoonやExpressなどでスタブを作る方法でも十分です。

一方で、APIが増え、仕様・テスト・ドキュメント・モックの同期が重要になる場合は、OpenAPI仕様からモックサーバーを生成する方法が実用的です。ApidogにOpenAPIファイルをインポートすれば、追加サーバーをホストせずにモックURLを作成できます。

DEV Community