Testing with Next.js

[delbaoliveira]

Hi there 👋

I'm Delba, Developer Advocate at Vercel. We recently released the first version of our Next.js Testing Docs which we want to continue iterating on.

It would be helpful to learn more about your Next.js testing story and any suggestions of how we could improve.

I've provided some prompts below to help you get started!

---

Reminder: This discussion will be moderated. Please read our Code of Conduct. Comments that do not meet CoC will not be accepted.

[delbaoliveira]

1. How do you currently test your Next.js applications? What tools and packages do you use and why? 👇

[kettanaito]

@eric-burel, bear in mind that MSW solves API mocking on any level—both browser and Node.js—using the same set of request handlers (a single source of truth for mocks). Its Next example illustrates how it can be used to intercept requests made in server-side hooks of Next.

[eric-burel]

Ha great news I didn't know that, I like that the implementation is not too intrusive. Initially I was thinking more about something that would be a standalone server, completely outside of Next, but that would raise a ton of issues like how to reuse the mocks in unit tests as well and in particular how to keep them typed with TypeScript. I like your solution.

[kettanaito]

@eric-burel, the cost of a standalone server for mocking alone can hardly be justified. We're designing our tools to be implementation-agnostic and letting you reuse the mocks everywhere. I'd highly recommend following this approach instead of configuring the same thing (API mocking) individually for each tool and workflow you have. In the end, there's a single intention—mock API calls. It shouldn't matter who makes those calls and where: whether it's a Cypress test or a Storybook component. If we lower the mock configurations to those individual tools, we'll end up with different setups for the same thing. I'm convinced that API mocking is a global thing and must be configured once.

[eric-burel]

Gave a shot at MSW today, I can finally get rid of all my clumsy Apollo mock providers :) I think that's the way to go in a modern testing architecture. I don't know if the wording is common yet but that's what they call "holistic testing" at Storybook. By that they mean the Story is the single source of truth for component testing => you should be able to use them for developing your component, in 3rd party tools like Jest, or Cypress if it makes sense, to do regression testing, to share with business team etc.
MSW feels the same on the API level, as you can use it in any tool, and even outside of testing (eg mocking an API during early stage development), with the same mocks. The graphql API makes sense (contrary to Apollo own MockedProvider...) and efficient.
However, I fail to see how Next could integrate it better. It seems to me that integration has to be done tool by tool (Jest, Storybook, Cypress...), and I will do so in my own boilerplate (VulcanNext), but I don't think you could have something "out-of-the-box" in Next am I right?
Maybe a demo of the hardest part, which is mocking SSR in Cypress tests of the Next.js app? I still don't know how I am expected to configure MSW for this scenario. Probably using a custom server similar to what is now demoed in "@cypress/mock-ssr" package?

[eric-burel]

I've just given a shot at https://github.com/mfrachet/cypress-audit to add Lighthouse to the Cypress testing workflow (+ optionnaly Pa11y but it's not MIT, it's a copyleft license) => works like a charm

[delbaoliveira]

2. What are some things that are working well? What blockers have you come across? 👇

[bscaspar]

@JessicaSachs done! #20487 Thank you for the response!

[leosuncin]

@bscaspar the problem is in cypress/tsconfig.json

https://github.com/bscaspar/cypress-next-import-error-example/blob/864ede4aaa43e97587449b16eb390043f5f71a22/cypress/tsconfig.json#L6

Change the baseUrl to .. and that will fix it

{
  "compilerOptions": {
    "noEmit": true,
    "allowJs": true,
    "types": ["cypress"],
    "baseUrl": ".."
  },
  "include": ["**/*.*"]
}

[bscaspar]

Another blocker I ran into was automation for running Cypress tests on Vercel preview deployments -> e.g. I push code to a branch, Vercel deploys to the preview environment, and my Cypress e2e tests automatically run. I was able to build a working Github action using this blog as a resource: https://glebbahmutov.com/blog/develop-preview-test/, here's the current version of my Github action:

name: ci
on:
  [deployment_status]

jobs:
  e2e:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Cypress run
        uses: cypress-io/github-action@v2
        env:
          CYPRESS_BASE_URL: ${{ github.event.deployment_status.target_url }}

The current documentation on the nextjs site only includes details and links on how to run the Cypress action using a localhost deployment, not grabbing the latest preview deployment URL. Testing against localhost gets complicated in Github actions once you start using env vars. It doesn't seem quite as simple as copy/paste the existing Cypress action and hit deploy.

I was thinking I would find better guidance around this topic since Vercel generally does a great job with automation and documentation.

This is really the first iteration of this job. The next step to this testing process is building additional steps where, if I'm deploying to prod and the tests fail, cancel the deployment.

[frattaro]

SWC can't do code coverage

[Vinnl]

Not sure if you're still taking feedback here, but Jest is getting long in the tooth, and it's starting to get more and more noticeable. Some examples:

• It regularly happens that some third-party dependency uses some ES module setup that Jest stumbles over.
• The order of imports and jest.mock calls affect the successful running of your tests in unpredictable ways.
• Coverage with V8 (possibly only in combination with source maps) is pretty unpredictable too, with e.g. lines containing only a single closing bracket being marked as uncovered, or lines only being marked as covered when their tests are executed in isolation.
• The Next.js app router docs hardly mention (unit) testing, and no longer even have a dedicated testing page.

A blessed "just works" unit testing story for Next.js tops my wish list at this point in time :)

[delbaoliveira]

3. What's not clear about testing with Next.js or FE testing in general? What would you like to learn more about? 👇

[gvocale]

How do you get next/images to work in Cypress Component Testing. I get a url like this in the DOM

/_next/image?url=imagename.jpg&w=1920&q=75

But it is blank

[devdjdjdj]

A guide for testing API routes, as suggested by @devdjdjdj: #10967 (comment). Also Ted Kesgar on Twitter.

We ended up using next-test-api-route-handler for testing API routes. It works fine so far.

[moshie]

I don't think there is a clear solution for mocking server side requests in getServerSideProps in cypress.

There is https://mswjs.io/ but it's not documented in NextJS

[AndrewSmir]

Hi! Has anyone been able to mock modules since Next 12? As Next 12 switched to the Rust compiler, rather than the Babel one,
"jest.mock" no longer works.

foo-bar-baz.ts
export const foo = 'foo';

jest.mock('../foo-bar-baz', () => {
  const originalModule = jest.requireActual('../foo-bar-baz');
  return {
    __esModule: true,
    ...originalModule,
    foo: 'mocked foo',
  };
});

test('should do a partial mock', () => {
  expect(foo).toBe('mocked foo'); // Fail: foo is still 'foo'
});

[pzi]

1. a thing that worked before next 12.2: testing the next/head: we have a custom metadata component that has a bunch of logic to display the correct meta data based on a given page and what's been set up in the headless CMS. Would be good to have some guide around how to test that. With the latest changes, the header manager is different and our tests are now failing.
2. next/router: we have some components that display a modal and block navigation (by throwing an error literal) that we would like to test. We currently maintain a mocked version of next/router to make our tests work but these have always been a struggle. Given the changes in 12.2 as well where the router has a context now, things have changed again.

[delbaoliveira]

4. Are there any community packages, articles, or videos that you have found helpful? Give them a shout-out 🎉

[delbaoliveira]

That's a good article @smhmd!

[leosuncin]

Stub Network Calls Made by Next.js App in getServerSideProps Method

[eric-burel]

Storybook Addon Next Router => best package currently for mocking the router in Storybook. The one linked currently in the documentation is described as being for "Storybook" but it's actually better for Jest (https://github.com/scottrippey/next-router-mock).

[devdjdjdj]

For testing API routes checkout : next-test-api-route-handler

[kuroski]

I've recently written this article regarding that 😄

Writing tests for Next.js, next-auth, Prisma using Playwright and msw

[delbaoliveira]

5. Post here any of your open GitHub discussions or issues related to testing. 👀

[delbaoliveira]

Thanks for the suggestion @bmuenzenmeyer. This is a bit similar direction we'd like to go. Something that would include the basic configuration for our users to get started. cc @mrmckeb 🙂

[leosuncin]

How to mock router in unit tests, it's unnecessary difficult #13891 and when you solve a way to do it #23911 it breaks because a mayor version change, all of these due the fact we need to "hack" private APIs to make it work

[eric-burel]

I've opened a PR about full-stack testing with Jest: #21800
When using API routes, ideally you would define a client and a server project to separate those tests.

[shubhsk88]

What is the best way to instrument getStaticPaths? I have been trying to get coverage using the cypress test but am unable to go through the getStaticPaths and getStaticProps as I think next build these pages in build time so there is no way for cypress to get them in the coverage? It would be great to document this part in nextjs docs to test this fetching functions as well

[zaru]

How should I unit test middleware? I tried using Vitest but couldn't figure out how to create a NextFetchEvent instance. I tried using FetchEvent instead but that doesn't seem like a good approach.

[JessicaSachs]

WRT using a stand-alone node server to mock network requests, before I had Cypress to mock requests/responses, I used Mountebank <https://github.com/bbyars/mountebank> with decent success.

…

On Mon, Sep 6, 2021 at 3:44 AM Eric Burel ***@***.***> wrote: MSW seems a nice tool for unifying the way we mock frontend requests across frameworks. But first, it's not very good for Graphql, because in GraphQL you have only one endpoint that can receive many different request. You would prefer mock-apollo-client <https://www.npmjs.com/package/mock-apollo-client>, if you use Apollo. Also for the backend calls there is still something to invent/discover that would catch requests at the network level. I am pretty sure it's doable in Node, a kind of proxy whose sole role is to intercept all requests on localhost:XXX, mock some of them, let the other slip. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28173 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVL4BDA3VJNWD5GLWKVTT3UARWPFANCNFSM5CIB7XVA> .

[ahmed-adly-khalil]

First of all the docs look great, it would be great to add some use case specific code examples/youtube videos for stuff like:

• different CMS like contentful, storyblok,... etc
• ecommerce apps like nextJS commerce

[piyushgarg-dev]

Hi team, I am trying to migrate from next.js 11 to 12 but I am facing issues in doing so. Can you please help me out?

next.config.js

// next.config.js
/* eslint @typescript-eslint/no-var-requires: "off" */
const withPlugins = require('next-compose-plugins');
const offline = require('next-offline');
const optimizedImages = require('next-optimized-images');
const CopyPlugin = require('copy-webpack-plugin');
const path = require('path');
const withImages = require('next-images');

const nextConfig = {
  target: process.env.NODE_ENV !== 'production' ? 'server' : 'serverless',
  i18n: {
    locales: ['en', 'de', 'fr'],
    defaultLocale: 'en',
  },
  dontAutoRegisterSw: true,
  generateSw: false,
  devSwSrc: './public/static/sw.js',
  workboxOpts: {
    swSrc: './public/static/sw.js',
    swDest: './public/static/service-worker.js',
  },
  images: {
    disableStaticImages: true,

    domains: ['trryst-dev.imgix.net', ''],
  },
  webpack5: true,
  typescript: {
    // !! WARN !!
    // Dangerously allow production builds to successfully complete even if
    // your project has type errors.
    // !! WARN !!
    //ignoreBuildErrors: true,
  },
  // Exposes Server ENV Vars To Client Using Webpack
  env: {
    AUTH0_CLIENT_ID: process.env.AUTH0_CLIENT_ID,
    AUTH0_DOMAIN: process.env.AUTH0_DOMAIN,
    BASE_APIPATH: process.env.STAGE === 'dev' ? 'http://localhost:8080' : process.env.ROOT_URL,
    //AWS_APIPATH: 'https://o4xqxux7eh.execute-api.eu-west-2.amazonaws.com/dev',
    //AWS_APIPATH: 'https://w2bytuti78.execute-api.eu-west-2.amazonaws.com/prod',
    AWS_APIPATH: process.env.AWS_APIPATH,
    PUBNUB_PUBLISH_KEY: process.env.PUBNUB_PUBLISH_KEY,
    PUBNUB_SUBSCRIBE_KEY: process.env.PUBNUB_SUBSCRIBE_KEY,
    GA_TRACKING_ID: process.env.GA_TRACKING_ID,
    TINYMCE_KEY: process.env.TINYMCE_KEY,
    TAWKTO_PROPERTY_ID: process.env.TAWKTO_PROPERTY_ID,
    TAWKTO_KEY: process.env.TAWKTO_KEY,
    STAGE: process.env.STAGE,
  },
  resolve: {
    alias: {
      '@mui/material/styles': require.resolve('@mui/material/styles'),
    },
  },
  webpack(config, options) {
    const { isServer } = options;
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
    config.module.rules.push({
      test: /\.(mp3|wav|mpe?g|ogg|gif)?$/i,
      exclude: config.exclude,
      use: [
        {
          loader: require.resolve('file-loader'),
          options: {
            limit: config.inlineImageLimit,
            publicPath: `${config.assetPrefix}/_next/static/images/`,
            outputPath: `${isServer ? '../' : ''}static/images/`,
            name: '[name]-[hash].[ext]',
            esModule: config.esModule || false,
          },
        },
      ],
    });
    return config;
  },

  headers: {
    source: '/api/:path*',
    headers: [
      { key: 'Access-Control-Allow-Credentials', value: 'true' },
      { key: 'Access-Control-Allow-Origin', value: 'https://chatserver.vboard.tk' },
      { key: 'Access-Control-Allow-Methods', value: 'GET,OPTIONS,PATCH,DELETE,POST,PUT' },
      {
        key: 'Access-Control-Allow-Headers',
        value:
          'X-CSRF-Token, X-Requested-With, Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version',
      },
    ],
  },
};

const withTM = require('next-transpile-modules')([
  '@fullcalendar/react',
  '@fullcalendar/daygrid',
  '@fullcalendar/interaction',
  '@fullcalendar/list',
  '@fullcalendar/timegrid',
  '@fullcalendar/timeline',
  '@fullcalendar/common',
]);

module.exports = {
  //below completely for selfhosted tinymce... ditch if not using it
  swcMinify: true,
  webpack: (config, { buildId, dev, isServer, defaultLoaders, webpack }) => {
    config.plugins.push(
      new CopyPlugin([
        {
          from: path.join(__dirname, 'node_modules/tinymce/skins'),
          to: path.join(__dirname, 'public/assets/libs/tinymce/skins'),
        }, /// Copy to public folder
      ]),
    );
    return config;
  },
  webpackDevMiddleware: config => {
    return config;
  },
};

module.exports = withPlugins([[offline], [withTM], [withImages, { inlineImageLimit: false }]], nextConfig);

Error:
TypeError: config.externals.map is not a function

Screenshots:

Thanks in advance

[bb-in-hoodie]

It would be great if you make a guideline of where to put our test codes.

In (non-Next.js) React development, there are three common directory structures for testing.

1. create a test code right next to its corresponding js/ts file

   src
    └ components
      └ header
         └ HeaderA.tsx
         └ HeaderA.test.tsx
         └ HeaderB.tsx
         └ HeaderB.test.tsx
      └ footer
         └ ...
   

2. create __tests__ folder under each subdirectories

   src
    └ components
      └ header
         └ __tests__
           └ HeaderA.test.tsx
           └ HeaderB.test.tsx
         └ HeaderA.tsx
         └ HeaderB.tsx
      └ footer
         └ __tests__
         └ ...
   

3. totally isolates the tests folder from components folder

   src
    └ components
      └ header
         └ HeaderA.tsx
         └ HeaderB.tsx
      └ footer
         └ ...
    └ tests
      └ header
         └ HeaderA.test.tsx
         └ HeaderB.test.tsx
      └ footer
         └ ...
   

In my opinion, the third option is worst since it forces you to make a twin directory structure all the time. But since Next.js discourages you to put any non-page codes to /pages folder, you cannot choose the first and the second options.

Of course you may replicate the same structure of /src directory to /tests directory, but it would be cumbersome and hard to maintain.

src
  └ components
    └ header
      └ ...
    └ footer
      └ ...
  └ pages
    └ [slug]
    └ search
  └ tests
    └ components
      └ header
        └ ...
      └ footer
        └ ...
    └ pages
      └ [slug]
      └ search

And also you might choose different rules for each components and pages folder, but using two different directory structures in a single project doesn't sound nice to me.

If there is any guideline about test code directory structure, it would be helpful to someone who is pretty new to both testing and Next.js (like me) :)

[bb-in-hoodie]

I use 2 for the following reason: I collocate unit test with other testing resources, namely fixtures, but also Storybook stories which I use as the basis for defining unit test (this way I literally see the component and play around with it manually, before I start writing unit test). So a collocated folder is helpful.

is it okay to place testing codes for pages to /pages/.../__tests__?
I thought it might be also discouraged since it would be considered as a 'non-page code'.

[eric-burel]

No pages are an edge case indeed. You can play around with extensions, but not folders so __tests__ would end up appearing in your sitemap, you don't want that.
What I've tried is having components/_pages where I put all the React logic and tests. The in pages/ I import this code. Basically pages files are only exporting the right component, maybe running a few hooks, and defining Data fetching methods.
However, this is not the final best solution, just my first attempt.

[balazsorban44]

you can colocate tests next to pages, see https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions#including-non-page-files-in-the-pages-directory

[bb-in-hoodie]

you can colocate tests next to pages, see https://nextjs.org/docs/api-reference/next.config.js/custom-page-extensions#including-non-page-files-in-the-pages-directory

I've read it before but I didn't follow it because "changing every page file's extension just to store test codes in 'post' directory" idea didn't sound good for me at that time. (why can't we just choose the extensions to exclude from building process, not those to include in the process?).

Bu it still might be an option for sure. Thank you :)

[bb-in-hoodie]

well honestly speaking, using .page extension looks better than I thought :P

[zhex900]

Hi,
I am not sure this is the right place to ask.

How do you test dynamic page [slug].tsx using react testing library?

I can't import [slug].tsx

[philwolstenholme]

An example of a Jest test that tests a file using import { cookies } from 'next/headers' would be great, as well as an example of how to test a component that uses import 'server-only';

See #44270

[tkrotoff]

@delbaoliveira

I've read the doc and I see several issues:

E2E tests should be mentioned last

The first thing you mention are E2E tests like it's the most important thing, this should be the last thing mentioned here's why:

Ham Vocke, martinFowler.com - The Practical Test Pyramid, 2018

https://martinfowler.com/articles/practical-test-pyramid.html#End-to-endTests

Due to their high maintenance cost you should aim to reduce the number of end-to-end tests to a bare minimum.
End-to-End tests come with their own kind of problems. They are notoriously flaky and often fail for unexpected and unforeseeable reasons. Quite often their failure is a false positive. The more sophisticated your user interface, the more flaky the tests tend to become. Browser quirks, timing issues, animations and unexpected popup dialogs are only some of the reasons that got me spending more of my time with debugging than I'd like to admit.

Mike Cohn, Succeeding with Agile, 2010

If you're building an e-commerce site your most valuable customer journey could be a user searching for a product, putting it in the shopping basket and doing a checkout. That's it. As long as this journey still works you shouldn't be in too much trouble. Maybe you'll find one or two more crucial user journeys that you can translate into end-to-end tests. Everything more than that will likely be more painful than helpful.

“Why We Killed Our End-to-End Test Suite”, 2021/09/24

Point 6: “Not efficient. Few bugs caught in this stage. One experiment suggested that, for every 1000 runs, we had 42 failures, only 1 bug”

https://building.nubank.com.br/why-we-killed-our-end-to-end-test-suite/
https://news.ycombinator.com/item?id=28643848

E2E tests are the last thing you write when everything else has been done. If it’s the first and/or only thing you do, you should reconsider.

Cypress is a good but Playwright is superior and thus should be favored

https://twitter.com/housecor/status/1597954687705104385

https://twitter.com/garybernhardt/status/1605635546952261632

https://twitter.com/housecor/status/1525205004637839361

You can find more comments about Playwright vs Cypress on Reddit, Hacker News, Twitter...

Conclusion: suggested order of sections

1. React Testing Library with Jest/Vitest
2. Playwright
3. Cypress

(the opposite of what you are currently doing: 1. Cypress, 2. Playwright, 3. React Testing Library)

[tkrotoff]

If the goal is to spread testing among developers then consider these things first:

• Add unit tests to Next.js examples: there are 343 examples and only 3 of them are tested
• Provide mocks for you APIs out of the box, for example React Router provides mocks and document them: https://v5.reactrouter.com/web/guides/testing, https://testing-library.com/docs/example-react-router/
  • current solution for mocking routing is a 3rd party package that does not support next/navigation
• Do not break MSW: RFC: "registerAfterEnv" hook for "instrumentation" #56446

[eric-burel]

Your sources are awesome but I would not completely agree with the proposed order. I feel like modern testing tools, like Cypress and Playwright, may invalidate the conclusion that e2e tests are necessarily extremely costly/slow compared to unit test. Particularly now they start supporting component-level testing, so the same tool can also be used for more granular tests.
Regarding Testing Library + Jest/Vitest, as fantastic as those tools are, the lack of visual feedback makes me quite slower in practice. The only way I could get really productive with them is by using Storybook. This lets me "see" the test while I write it.
So in the end those decisions might be quite contextual and dependent on the criticity of testing your components, your teams skills, the technological choices etc. etc.

[tkrotoff]

@eric-burel

may invalidate the conclusion that E2E tests are necessarily extremely costly/slow compared to unit [...] they start supporting component-level testing

E2E means end to end, "de bout en bout" (vertically and/or horizontally). Component-level testing with Cypress or Playwright is by definition not E2E.
Running a test in a web browser does not make it a E2E test (and vice-versa: you can E2E test a native app and obviously you don't rely on a web browser to do that).

React Testing Library relies on JSDOM (or Happy DOM) which is "a pure-JavaScript implementation [for] the DOM and HTML standards".
It is a lightweight specialized web browser: 590 kB vs Firefox 127 MB. It reuses current JS interpreter, no UI, tons of things not implemented we don't need (and some we need - shortcomings)…
Playwright and Cypress component testing implementations can be fast, but I doubt they can be as fast as JSDOM or Happy DOM.

The visual feedback is a killer feature (improved DX) + overcoming the shortcomings of a lightweight web browser might be the future of unit testing web apps, we will see (Cypress and Playwright component testing are recent features).

[jwickens]

Here's an example with e2e testing with playwright, with recording of API calls both client and server side: https://github.com/jwickens/next-page-e2e-testing/tree/main

[kelvyn-thai]

Issue: Unable to Mock API Calls in Next.js 15 Server Components (SSR)

Problem Statement

I’m struggling to mock API requests inside Next.js 15’s Server Components (SSR). My homepage fetches data from GitHub’s API (name, bio, avatar) on the server-side and renders it. However, I cannot find a way to intercept or mock this request properly.

What I’ve Tried So Far

I’ve attempted the following mocking strategies, but none have worked for server-side rendering:
• Mock Service Worker (MSW) → Works for client-side requests but does not intercept SSR fetch calls.
• Supertest → Works for API route tests, but cannot mock external API calls inside SSR.
• Mocking fetch() globally → Doesn’t seem to override Next.js’s internal fetch handling.
• Jest jest.mock() on the service function → Works in unit tests, but does not apply inside full Next.js SSR lifecycle.

Current Workaround

For now, I’m using E2E testing to check SSR behavior. However, this is not ideal because:
• It depends on real API data (which changes across environments: prod/staging/dev).
• It cannot isolate tests properly.
• It slows down test execution compared to unit/integration testing.

import { faker } from "@faker-js/faker";
import * as cheerio from "cheerio";
import { http, HttpResponse } from "msw";
import { setupServer, SetupServerApi } from "msw/node";
import request from "supertest";
import { UserEntity } from "@/schemas/github";
import githubService, { GithubService } from "@/services/Github.services";

describe("Test APP", () => {
  let server: SetupServerApi;
  const mockUsername = faker.internet.username();
  const mockUser: UserEntity = {
    avatar_url: faker.image.avatar(),
    name: faker.person.fullName(),
    email: faker.internet.email(),
    bio: faker.person.bio(),
  };

  beforeAll(() => {
    const handlers = [
      http.get("https://api.github.com/users/:username", ({ params }) => {
        console.debug("🔍 MSW intercepted request:", params.username);
        return HttpResponse.json({ ...mockUser });
      }),
    ];

    server = setupServer(...handlers);

    server.listen();

    console.debug("✅ MSW Server Started");
  });

  it("Should intercepted request by MSW", async () => {
    const response = await githubService.getUserInfo(mockUsername);

    expect(response).toMatchObject(mockUser);
  });

  it.only("Should render correctly Greetting", async () => {
    jest.spyOn(githubService, "getUserInfo").mockResolvedValue(mockUser); // not work

    jest
      .spyOn(GithubService.prototype, "getUserInfo")
      .mockResolvedValue(mockUser); // not work too

    const response = await request("http://localhost:3000").get("/"); // Fetch SSR HTML

    expect(response.status).toBe(200);

    const $ = cheerio.load(response.text); // Parse HTML

    // const avatarUrl = $("[data-testid='avatar']").attr("src");
    const name = $("[data-testid='name']").text();
    const bio = $("[data-testid='bio']").text();

    // expect(avatarUrl).toBe(mockUser.avatar_url);
    expect(name).toBe(`Hello, I am ${mockUser.name}`);
    expect(bio).toBe(mockUser.bio);
  });

  afterEach(() => {
    server.resetHandlers();
  });

  afterAll(() => {
    server.close();
  });
});

I want to:
1. Intercept or mock the API request inside Next.js 15’s Server Component lifecycle.
2. Ensure the page still renders correctly with mocked data.
3. Run reliable tests without needing external API calls.