ワークフロースのヒント

Mirageはアプリケーションへの統合をスムーズにするように設計されており、クイックスタートのいずれかを実行した場合は、プロジェクトに最小限のセットアップが既に存在する可能性があります。

Mirageコードの記述に慣れてきたら、これらのヒントに従って開発者エクスペリエンスを最適化し、あなたとあなたのチームがMirageを最大限に活用できるようにしてください。

コンポーネントファイルやテストファイルに直接Mirageを使用して一度限りのサーバーを作成できますが、開発環境とテスト環境の両方で共有できるように、モックサーバーの定義を集中化するのが一般的です。結局のところ、本番環境では、アプリケーションは単一のAPI契約を実装する単一のサーバーと通信します！したがって、単一のサーバー定義を使用することで、Mirageが使用されているすべての場所で一貫性のあるモックAPI契約を維持するのに役立ちます。

そのため、開発またはテストのために既に開始したMirageサーバーがある場合は、開発環境とテストの両方で使用されることが明確な場所に移動してください。

共有サーバーを定義する一般的な場所は、src/server.jsです。

└── src
    ├── App.js
    ├── App.test.js
    └── server.js

次に、server.jsファイルから、Mirageサーバーの起動に使用できる関数をエクスポートします。

// src/server.js
import { createServer, Model } from "miragejs"

export function makeServer({ environment = 'test' }) {
  return createServer({
    environment,

    models: {
      movie: Model,
    },

    routes() {
      this.namespace = "api"

      this.resource("movie")
    },
  })
}

ここでは、environmentキーを持つオプション引数を受け入れるmakeServer関数を定義しています。test環境はMirageの人工的な遅延をオフにし、初期のseeds()を無視し、コンソールへのログを無効にします。複数のテストでmakeServerをインポートする可能性が高い一方で、開発環境では1か所のみインポートするため、環境をtestにデフォルト設定するのは妥当な選択です。もちろん、プロジェクトにとって意味のある追加の引数を受け入れるようにこの関数をカスタマイズできます。

これで、この関数をインポートして開発環境でMirageを起動できます。

例えば、React アプリでは、index.js がしばしば「ブートストラップ」ファイルとして機能するため、そこで Mirage を開始することができます。

// index.js
import React from "react"
import ReactDOM from "react-dom"
import App from "./App"
import { makeServer } from "./mirage"

makeServer({ environment: "development" })

ReactDOM.render(<App />, document.getElementById("root"))

これで、通常の React アプリ開発時（npm run start）に Mirage が実行されるようになります。

本番環境では、Mirage を実行したくない場合があります（アプリが実際のネットワークリクエストを行う必要があるため）。そのため、次のような処理になることがあります。

// index.js
import React from "react"
import ReactDOM from "react-dom"
import App from "./App"
import { makeServer } from "./mirage"

if (process.env.NODE_ENV === "development") {
  makeServer({ environment: "development" })
}

ReactDOM.render(<App />, document.getElementById("root"))

process.env.NODE_ENV は、アプリのビルド環境を公開する一般的なグローバル変数であり、Mirage の起動を条件付きで行うために使用できます。

理想的には、本番環境で Mirage を使用しない場合、Mirage のライブラリコードとサーバー定義コードが本番バンドルに含まれないようにする必要があります（プロトタイプを作成していて有効にしたい場合を除く）。これを実現する方法は、ビルドツールの設定によって異なりますが、多くの場合、上記のようなチェックを追加することで、Mirage がビルドから自動的にツリーシェイクされます。

テストでも、新しく作成した中央集約型のサーバー定義を使用できます。makeServer 関数をテストでインポートし、各テストの前に使用して Mirage を開始します。

// tests/home-test.js
import { startMirage } from "./mirage"

describe("homepage", function () {
  let server

  beforeEach(() => {
    server = startMirage()
  })

  afterEach(() => {
    server.shutdown()
  })

  it("shows the movies", function () {
    server.createList("movie", 10)

    cy.visit("/")

    cy.get("li.movie").should("have.length", 10)
  })
})

Mirage サーバーインスタンスには、各テスト後に環境をクリーンアップするために呼び出す必要があるshutdown メソッドがあります。

テストで共有サーバー定義を使用している場合でも、非定型的な状況下でのアプリの動作をテストするために、一度限りの変更を適用できます。例えば、アプリが 500 サーバーエラーにどのように応答するかをテストする場合、グローバルな Mirage サーバー定義を変更する代わりに、テスト内で単一の API ルートを変更するだけで済みます。

// tests/home-test.js
import { startMirage } from "./mirage"
import { Response } from "miragejs"

describe("homepage", function () {
  let server

  beforeEach(() => {
    server = startMirage()
  })

  afterEach(() => {
    server.shutdown()
  })

  it("shows an error if the server is down", function () {
    // Override the existing /movies route handler, just for this test
    server.get("/movies", () => new Response(500))

    cy.visit("/")

    cy.get("h1").should("contain", "Whoops! Our site is down.")
  })
})

サーバーをシャットダウンして各テストで新しいサーバーを起動するため、これらの変更は変更を加えたテストのみに適用されます。

これで、Mirage サーバーを定義および拡張する場所が1か所に集約され、テストで簡単に使用できるようになりました。

屈折の調整

他のツールとの比較

ワークフロースのヒント

開発とテスト間でサーバーを集中化し、共有する