Effective Testing Strategies for Network Calls in Next.js Apps

Introduction

Testing network interactions in web applications, especially in frameworks like Next.js, is pivotal to building reliable software. However, developers often wonder whether some unit tests, particularly those that mock internal functions instead of the actual network requests, are truly valuable or just redundant noise. This article addresses this common concern by exploring best practices in testing network calls in Next.js apps and provides actionable advice on structuring tests to maximize their effectiveness.

Understanding the Challenge: Testing Network Calls

When your application includes primary functions that wrap a generic function like customFetch which internally uses the browser's fetch, it's tempting to mock customFetch in unit tests to isolate logic. However, there are several levels at which network interactions can and should be tested:

Levels of Testing Network Requests

| Level | What is tested | Tools & Techniques
| | |---| | -------------------------------------------------- | ---------------------------------| | Unit Tests | Logic in your individual functions and modules | Jest mocks, testing internal logic| | Mocking at Fetch | Simulating network responses | Mock Service Worker (MSW), jest-fetch-mock| | Integration Tests | Realistic interactions between components & APIs | React Testing Library + MSW, Cypress|

Why Mocking `customFetch` Alone is Sometimes Insufficient

Mocking customFetch verifies the call was made with expected arguments but doesn't test the actual network call behavior.
It often tests the mock itself rather than the logic or response handling.
Simulating fetch responses more closely mirrors real-world scenarios including success and failure.

Recommended Testing Approach

1. Unit Test Pure Logic

Write unit tests for functions that contain logic independent of network calls without mocking internal fetch wrappers excessively.

typescript
function sum(a: number, b: number): number {
  return a + b;
}
// Unit test for pure function
expect(sum(2, 3)).toBe(5);

2. Mock Network at the Fetch Layer

Instead of mocking your customFetch in every unit test, mock the actual fetch or network using libraries like Mock Service Worker (MSW) which intercepts requests realistically.

Example using MSW with Jest:

typescript
import { rest } from 'msw'
import { setupServer } from 'msw/node'

const server = setupServer(
  rest.get('/api/services/identity/:id', (req, res, ctx) => {
    return res(ctx.status(200), ctx.json({ userId: req.params.id }));
  })
)

beforeAll(() => server.listen())
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

// Now write tests where fetch is mocked realistically

3. Integration Tests Cover Overall Behavior

Write tests that actually invoke the real network layer (or mock at HTTP) and verify the entire flow, ensuring proper handling of different network outcomes.

4. Avoid Over-Mocking

Excessive mocking of internal wrappers without testing behavior leads to brittle, less meaningful tests.

Realistic Example: Testing Primary Functions in Next.js

Assume your app has primary functions like getIdentity calling customFetch:

typescript
async function getIdentity(id: string): Promise<any> {
  return await customFetch(`/api/services/identity/${id}`, 'GET')
}

async function customFetch(path: string, method: 'GET' | 'POST', body?: any) {
  // perform fetch
}

Problematic Unit Test Example:

typescript
// Jest mock for customFetch
jest.mock('../utils/customFetch')
import customFetch from '../utils/customFetch'
import { getIdentity } from '../api'

test('getIdentity calls customFetch with correct args', async () => {
  const mockResponse = { user: '123' }
  (customFetch as jest.Mock).mockResolvedValueOnce(mockResponse)

  const result = await getIdentity('123')

  expect(customFetch).toHaveBeenCalledWith('/api/services/identity/123', 'GET')
  expect(result).toEqual(mockResponse)
})

This only tests the mock and call signature.

Improved Testing with MSW:

You mock at the network layer; your tests look like:

typescript
import { rest } from 'msw'
import { setupServer } from 'msw/node'
import { getIdentity } from '../api'

const server = setupServer(
  rest.get('/api/services/identity/:id', (req, res, ctx) => {
    return res(ctx.json({ user: req.params.id }))
  })
)

beforeAll(() => server.listen())
afterEach(() => server.resetHandlers())
afterAll(() => server.close())

test('getIdentity returns user data', async () => {
  const result = await getIdentity('123')
  expect(result.user).toBe('123')
})

// Test network error handling
server.use(
  rest.get('/api/services/identity/:id', (req, res, ctx) => {
    return res(ctx.status(500))
  })
)

test('getIdentity handles errors gracefully', async () => {
  await expect(getIdentity('123')).rejects.toThrow()
})

Visual: Testing Pyramid and Mocking Strategy

Software Testing Pyramid

Practical Applications

In Next.js apps, rely on strong unit tests for pure logic but prefer mocking at fetch/network layer for API wrappers.
Use integration tests with MSW or real environment for end-to-end assurance.
Monitor tests for redundancies, removing superficial mock tests that don't add value.

Conclusion

You are not losing your mind! Testing is nuanced, especially with network calls. While unit tests mocking customFetch prove call correctness, they often test the mock rather than real behavior.

For effective and meaningful coverage:

Mock the actual network at the fetch/request layer with tools like MSW.
Use integration tests for real behavior flows.
Avoid over-mocking internal wrappers and focus on behavior.

This approach reduces bloat and improves confidence in your tests.