next testmode 素振り
mugiためしてみる
mugi該当のPR
mugiコードやREADMEはこのあたり
mugiを見ると、next dev 起動時に --experimental-test-proxy を付与するのがポイントぽい
mugi
The "fetch loopback" mode can be configured in the playwright.config.ts or via test.use() with a test module. This option loops fetch() calls via the fetch() of the current test's worker.
fetchLoopback を使うと、現在のテストのworker上の fetch を使うようにできるぽい
mugitest 関数は、Playwrightの Custom Fixture
mugi元々の問題は↓のissue
Nodeでmswを動かす場合、httpやhttpsにパッチを当てて動かすが、Next.jsの場合はページごとのプロセスが都度生成されるため、パッチを引き継ぐことが出来なかったらしい
mugiPlaywrightのworkerの単位で http モジュール経由でhttpサーバーを立ててる
mugiリクエストをwrapして、↑で立てたhttpサーバーのportに対して流すようにしてるぽい
mugi- fixtureで立てたhttpサーバーはPlaywrightのworkerのプロセスに紐づいて生きてる
- mswでパッチを適用した場合、Playwrightのworkerが生きてる限りは有効
- Next側からのリクエストは↑を経由するため、Next側のプロセスの状態に関わらず、テスト上で設定したmswを経由してくれる
ということかもしれない
mugifetch-mock を使う方法で試す
muginpm install -D fetch-mock
Page
export default async function Home() {
const res = await fetch("https://jsonplaceholder.typicode.com/posts/1");
const json = await res.json();
return (
<main>
<dl>
<dt>id</dt>
<dd>{json.id}</dd>
<dt>title</dt>
<dd>{json.title}</dd>
<dt>body</dt>
<dd>{json.body}</dd>
</dl>
</main>
);
}
テスト
import { test, expect } from "next/experimental/testmode/playwright";
import fetchMock from "fetch-mock";
Object.assign(fetchMock.config, { Headers, Request, Response, fetch });
test.use({ nextOptions: { fetchLoopback: true } });
test("/", async ({ page, next }) => {
fetchMock.get("https://jsonplaceholder.typicode.com/posts/1", {
id: 123,
title: "Test Title",
body: "Test Body",
});
await page.goto("/");
const body = page.locator("body");
await expect(body).toHaveText(/123/);
await expect(body).toHaveText(/Test Title/);
await expect(body).toHaveText(/Test Body/);
});
パスした
モックのロジックを消すとちゃんと落ちる
mugiMSW使わなくても、これで十分事足りるケースも多いかも？
mugiOr use your favorite Fetch mocking library
に気をとられていたが、そもそも何も入れなくても引数の next 使えばモックできるぽい
mugiこれでいけた
import { test, expect } from "next/experimental/testmode/playwright";
test("/", async ({ page, next }) => {
next.onFetch((request) => {
if (request.url === "https://jsonplaceholder.typicode.com/posts/1") {
return new Response(
JSON.stringify({
id: 123,
title: "Test Title",
body: "Test Body",
}),
{ headers: { "Content-Type": "application/json" } }
);
}
return "abort";
});
await page.goto("/");
const body = page.locator("body");
await expect(body).toHaveText(/123/);
await expect(body).toHaveText(/Test Title/);
await expect(body).toHaveText(/Test Body/);
});
この next って何
mugiこのへんで定義してる
mugionFetch の実体は、NextFixtureのものが呼ばれる
mugi実際の動作時には、まずfetchリクエストがproxy によって拾われる
mugi↑での onFetch は、NextWorkerFixtureImpl のインスタンスにbindされてる
結果として、 this.proxyFetchMap に登録されてるハンドラが実行される
this.proxyFetchMap には、NextWorkerFixtureImplのonFetchを呼ぶと登録される
mugiNextWorkerFixtureImplのonFetch は、NextFixture のインスタンス生成時に呼ばれてる。
handlerとして渡されてるのは、NextFixtureImplのhandleFetch
mugiこの handleFetch の段階で、this.fetchHandlerがあれば実行されてるのがわかる。
これは、テスト側で next.onFetch を実行した場合に渡したものが設定されてる
というわけで、next.onFetchに渡したハンドラがモックとして動く
mugimsw 使ったのも試す
muginpm install -D msw して、次のテスト書けば終わり
import { test, expect, rest } from "next/experimental/testmode/playwright/msw";
test("/", async ({ page, msw }) => {
msw.use(
rest.get("https://jsonplaceholder.typicode.com/posts/1", (req, res, ctx) =>
res.once(
ctx.status(200),
ctx.json({
id: 123,
title: "Test Title",
body: "Test Body",
})
)
)
);
await page.goto("/");
const body = page.locator("body");
await expect(body).toHaveText(/123/);
await expect(body).toHaveText(/Test Title/);
await expect(body).toHaveText(/Test Body/);
});
next/experimental/testmode/playwright/msw に定義の test は、↑で見た NextFixtureとNextWorkerFixtureを使ったCustomFixtureを継承している。
その上で、 next.onFetch ですべてのリクエストをインターセプトして msw に投げてる。
mugiすべてをインターセプトするので、デフォルトのまま next/experimental/testmode/playwright/msw を使うと、msw向けのハンドラが存在しないAPIを呼び出した瞬間エラーになる
mugi自分で使うときとかは onUnhandledRequest の設定によって、モック化されていないAPIはスルーさせたりもできるが、現状これは error で固定されてる