Router Act Testing

Use this skill when writing or modifying tests that involve prefetch requests, client router navigations, or the segment cache. The createRouterAct utility from test/lib/router-act.ts lets you assert on prefetch and navigation responses in an end-to-end way without coupling to the exact number of requests or the protocol details. This is why most client router-related tests use this pattern.

When NOT to Use act

Don't bother with act if you don't need to instrument the network responses — either to control their timing or to assert on what's included in them. If all you're doing is waiting for some part of the UI to appear after a navigation, regular Playwright helpers like browser.elementById(), browser.elementByCss(), and browser.waitForElementByCss() are sufficient.

Core Principles

1. Use LinkAccordion to control when prefetches happen. Never let links be visible outside an act scope.
2. Prefer 'no-requests' whenever the data should be served from cache. This is the strongest assertion — it proves the cache is working.
3. Avoid retry/polling timers. The act utility exists specifically to replace inherently flaky patterns like retry() loops or setTimeout waits for network activity. If you find yourself wanting to poll, you're probably not using act correctly.
4. Avoid the block feature. It's prone to false negatives. Prefer includes and 'no-requests' assertions instead.

Act API

Config Options