7584b02b34
* Refactor data fetching to support getting headers * Relax `getNextPathnameInfo` type * Add test for middleware internal redirects * Export `ParsedRelativeUrl` type * Refactor `getMiddlewareEffects` * Move rewrite i18n test to middleware rewrite tests * Fix bug parsing pathname info * Normalize data requests to page requests for middleware * Ensure there is a header `x-nextjs-matched-path` for middleware rewrites on data requests * Extract `getDataHref` to a function * Stop using `getDataHref` for flight * Always set the query in `dataHref` independently of if it is SSG * Add test for recursive rewrites * Refactor dynamicPath validation to `matchHrefAndAsPath` * Add `dataHref` to `FetchDataOutput` * Extract `matchesMiddleware` function * Add `hasMiddleware` option to `fetchNextData` * Move preflight test * Remove preflight test * Add middleware prefetch tests * Remove preflight * Attempt to reduce bundle size Include `withMiddlewareEffects` and `matchHrefAndAsPath` into `router` Bring `getDataHref` back to `page-loader` Bring `resolveDynamicRoute` back to `router` * Reduce arg duplication for `withMiddlewareEffects` * Remove some async/await and spreads to reduce bundle size * Upgrade `edge-runtime` & clone `Request` on redirects to mutate headers * Add some rewrite tests Co-authored-by: Kiko Beats <josefrancisco.verdu@gmail.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> |
||
|---|---|---|
| .. | ||
| .stats-app | ||
| __mocks__ | ||
| development | ||
| e2e | ||
| integration | ||
| lib | ||
| production | ||
| unit | ||
| .gitignore | ||
| jest-setup-after-env.ts | ||
| readme.md | ||
| test-file.txt | ||
Writing tests for Next.js
Getting Started
You can set-up a new test using yarn new-test which will start from a template related to the test type.
Test Types in Next.js
- e2e: These tests will run against
next dev,next start, and deployed to Vercel - development: These tests only run against
next dev - production: These tests will run against
next start. - integration: These tests run misc checks and modes and is where tests used to be added before we added more specific folders. Ideally we don't add new test suites here as tests here are not isolated from the monorepo.
- unit: These are very fast tests that should run without a browser or running next and should be testing a specific utility.
For the e2e, production, and development tests the createNext utility should be used and an example is available here. This creates an isolated Next.js install to ensure nothing in the monorepo is relied on accidentally causing incorrect tests.
All new test suites should be written in TypeScript either .ts (or .tsx for unit tests). This will help ensure we catch smaller issues in tests that could cause flakey or incorrect tests.
If a test suite already exists that relates closely to the item being tested (e.g. hash navigation relates to existing navigation test suites) the new checks can be added in the existing test suite.
Best Practices
- When checking for a condition that might take time, ensure it is waited for either using the browser
waitForElementor using thecheckutil innext-test-utils. - When applying a fix, ensure the test fails without the fix. This makes sure the test will properly catch regressions.