テストを書いたことのあるプログラマーなら一度は「なんでテストが通らないんだ…？」と頭を抱えた経験があると思います。今回、私もまさにその状態に陥りました。それは、Next.js の Edge Runtime を使ったプロジェクトでのこと。Route Handler をテストしようとしたとき、あの忌々しい「is not a function」エラーに出くわしました。このエラーを克服するために試行錯誤した経験を、ここで共有します。同じ問題に悩む方の助けになれば幸いです。

問題に直面したときの状況

私が取り組んでいたのは、Next.js の Route Handler のテストでした。特に Edge Runtime を使う際には、Node.js 標準の Response と Next.js 独自の拡張 Response の間で競合が起こることがあります。その結果、NextResponse.json() を呼び出した瞬間に「is not a function」というエラーが発生してしまいました。

さらに、Jest を使ったテスト環境では、モジュールの読み込み順や jest.mock() の使い方次第で新たな問題が発生することがありました。このような細かいトラップがいくつも重なり、初めは手詰まり状態でした。

私が実践した解決策

いろいろ試してみた結果、以下の方法を組み合わせることで問題を解決できました。それぞれのアプローチを詳しく説明します。

1. Edge Runtime 対応のテスト環境を使用する

まず最初にやったのは、Jest のテスト環境を Edge Runtime に近づけることです。具体的には、@edge-runtime/jest-environment を testEnvironment に設定しました。これを導入することで、Next.js 独自の Web API 実装と Node.js のモック環境との競合を減らすことができました。

// jest.config.js の例
{
  "testEnvironment": "@edge-runtime/jest-environment"
}

これだけで、「is not a function」エラーの発生頻度がかなり減りました。

2. 過剰なモックを減らす

テストをシンプルに保つことも重要でした。Edge Runtime 対応のテスト環境を使う場合、Response.json() のモックは不要です。むしろ余計なモックを追加すると、新たな問題を引き起こす原因になりました。テスト対象の範囲を明確にし、必要最低限のモックだけを使うことで、問題を切り分けやすくなりました。

3. ビジネスロジックと Route Handler の分離

私が抱えていた最大の問題は、テスト対象の範囲が広すぎたことでした。Route Handler の中にビジネスロジックを直接埋め込んでしまっていたため、テストが複雑化していたのです。

そこで、ビジネスロジックを独立したクラスや関数に切り出しました。これにより、ビジネスロジックそのものは単体テストでカバーし、Route Handler 側ではそのロジックをモックするだけで済むようになりました。

4. モックの読み込み順序を明確化

Jest で ES Modules を使う際には、モジュールの読み込み順が非常に重要です。jest.mock() を使う場合は、import 文よりも前に記述しなければモックが効きません。また、テスト間でモジュールキャッシュの影響を受けないよう、jest.resetModules() や jest.isolateModules() を活用しました。

5. パスエイリアスでモジュール管理を簡素化

プロジェクトの規模が大きくなると、相対パスが複雑になりがちです。そのため、tsconfig.json や moduleNameMapper を活用して、パスエイリアスを設定しました。これにより、モジュール間のパス管理がスムーズになり、テストコードの可読性も向上しました。

実際のコード例

具体例を挙げると、次のようにビジネスロジックと Route Handler のテストを分離しました。

ビジネスロジックの単体テスト

// line-login-service.test.ts
describe("LineLoginService", () => {
  beforeEach(() => {
    global.fetch = jest.fn();
  });

  it("APIのURLが設定されていない場合", async () => {
    const service = new LineLoginService("");
    const result = await service.getLoginUrl();
    expect(result).toEqual({ error: "API URLが設定されていません" });
  });
});

Route Handler のテスト（ビジネスロジックをモック）

// route.test.ts
jest.mock("@line-login-service", () => ({
  LineLoginService: jest.fn().mockImplementation(() => ({
    getLoginUrl: jest.fn().mockResolvedValue({ url: "https://line.login.url" }),
  })),
}));

describe("LINE Login Route Handler", () => {
  it("正常にURLを返す", async () => {
    const response = await GET();
    const body = await response.json();
    expect(body).toEqual({ url: "https://line.login.url" });
  });
});

最後に

今回の経験を通じて、「テストはシンプルであるべき」という基本的な考え方の大切さを改めて感じました。また、Edge Runtime のような特殊な環境でのテストは独特な課題が伴いますが、環境を整えるだけでも問題解決の糸口が見えてきます。

もし同じような問題に直面している方がいたら、この経験が参考になれば嬉しいです。そして、「まだこうした方が良いよ」というフィードバックがあれば、ぜひ教えてください！