React Testing with Jest — Unmocked Analytics Breaks CI

Shipping a React app without tests is like deploying to production with your fingers crossed. At small scale it feels fine — until a refactor silently breaks the checkout flow at 2am on Black Friday and nobody catches it until the Slack alerts light up. Jest, paired with React Testing Library, is the industry-standard answer to this problem, and for good reason: it runs in milliseconds, integrates with CI/CD with zero ceremony, and forces you to think about your components from a user's perspective rather than an implementation detail perspective.

The real problem isn't knowing that you should test — it's knowing HOW to test well at an advanced level. Shallow rendering vs full mount, when to mock vs when to let real logic run, how async state updates inside act() actually work under the hood, how to test custom hooks without spinning up a full component — these are the questions that separate a test suite that gives you confidence from one that gives you false confidence and then breaks on the first real bug.

By the end of this article you'll be able to write async tests that don't produce act() warnings, mock API layers cleanly without leaking state between tests, test custom hooks in isolation, profile your test suite for slow runners, and debug the cryptic errors that Jest throws when React's scheduler and your test runner disagree. These are skills that show up directly in senior engineering interviews and in PR reviews at companies that actually care about quality.

What is React Testing with Jest?

React Testing with Jest is a core concept in JavaScript. Rather than starting with a dry definition, let's see it in action and understand why it exists.

Here's the thing: you don't test React components to hit a coverage number. You test them to know that when someone refactors the auth logic, the login button still works. That's the real win — a safety net that catches regressions before they reach production.

Think about the last time you pushed a change that broke something unrelated. It happens because JavaScript is dynamic — a change in one module can silently affect another. Tests catch this. But only if you're testing the right thing: user behavior, not implementation details.

A common question: should I test every component? No. Focus on critical user flows, edge cases, and any component that handles async logic, user input, or external dependencies. The rest? Smoke test them and move on.

A quick story: I once worked on a team that relied heavily on snapshot tests. Every time a designer tweaked a margin, the snapshot failed. Engineers would update the snapshot without reviewing the diff because it was always just the same margin change. One day, a developer accidentally removed the submit button from a form. The snapshot still passed because the margin changed too — they updated it all in one go. The button was gone from production for 4 hours. That's the cost of testing implementation instead of user-visible behavior.

/**
 * io.thecodeforge.testing — React Testing with Jest intro
 * Always use meaningful names, not x or n
 */

// Component to test
const LoginButton = ({ onClick, disabled = false, children }) => (
  <button onClick={onClick} disabled={disabled}>
    {children}
  </button>
);

// Test that verifies user behavior, not implementation
import { render, screen, fireEvent } from '@testing-library/react';

test('button calls onClick when clicked', () => {
  const handleClick = jest.fn();
  render(<LoginButton onClick={handleClick}>Log in</LoginButton>);
  
  fireEvent.click(screen.getByText('Log in'));
  
  expect(handleClick).toHaveBeenCalledTimes(1);
});

test('button is disabled when disabled prop is true', () => {
  render(<LoginButton onClick={() => {}} disabled>Log in</LoginButton>);
  
  expect(screen.getByText('Log in')).toBeDisabled();
});

Async Testing Patterns — waitFor, findBy, and act()

React components often update state asynchronously — after API calls, timers, or user interactions. Testing these requires special patterns.

waitFor is a utility that polls until the callback no longer throws. Use it when you need to wait for an assertion to pass over time. It checks every 50ms and times out after 1s by default. findBy* queries are syntactic sugar that call waitFor internally — they return a promise that resolves when the element appears.

The act() function is React's test helper that wraps state updates and effect dispatches. Every time your test triggers something that causes a re-render (e.g., fireEvent, userEvent), it must be wrapped in act. RTL does this automatically for most interactions — but not for all. When you see An update to ... inside a test was not wrapped in act(...), you need to explicitly wrap the cause of that update.

A common mistake is to assume that waitFor will always succeed — it will time out if the condition is never met. Always include a fallback or increase timeout only after confirming the root cause.

Here's a typical pattern: testing a component that fetches user data on mount.

One more nuance: waitFor doesn't retry forever. If your async operation takes longer than 5 seconds (increased timeout), your test times out. Always set a realistic timeout and ensure your mock resolves quickly — slow mocks cause flaky CI.

There's a lesser-known pitfall: if you use waitFor with an empty callback like waitFor(() => {}), it passes immediately because nothing throws. You must include at least one assertion inside the callback for it to poll meaningfully. The callback throws when an assertion fails, which triggers the next poll cycle until timeout.

import { render, screen, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import UserProfile from './UserProfile';
import { fetchUser } from './api';

jest.mock('./api');

beforeEach(() => {
  jest.resetAllMocks();
});

test('displays user name after fetch', async () => {
  fetchUser.mockResolvedValue({ id: 1, name: 'Alice' });
  render(<UserProfile userId={1} />);

  await waitFor(() => {
    expect(screen.getByText('Alice')).toBeInTheDocument();
  });
});

test('shows error state when API fails', async () => {
  fetchUser.mockRejectedValue(new Error('Network error'));
  render(<UserProfile userId={1} />);

  await waitFor(() => {
    expect(screen.getByText(/failed to load/i)).toBeInTheDocument();
  });
});

test('finding element with findBy', async () => {
  fetchUser.mockResolvedValue({ id: 1, name: 'Bob' });
  render(<UserProfile userId={1} />);

  const nameElement = await screen.findByText('Bob');
  expect(nameElement).toBeInTheDocument();
});

Mocking Strategies — jest.mock, Module Mocks, and SpyOn

Mocking is essential to isolate the component under test from its dependencies. Jest offers several ways to mock:

• jest.mock(modulePath, factory): Auto-mocks an entire module. The call is hoisted to the top of the file, so it runs before all imports. Use this for modules like API clients, analytics, or external libraries.
• Manual mocks: Create a __mocks__/ directory next to the module with the same filename. Jest uses this mock automatically when jest.mock is called.
• jest.spyOn(object, methodName): Creates a mock for a method on an existing object. It preserves the original implementation unless you call mockImplementation or mockReturnValue. Useful for partial mocking.
• jest.fn(implementation): Creates a standalone mock function. You can set return values, track calls, and inspect call history.

The key rule: mock at the module boundary, not the function call. If you import fetchUser from ./api, mock ./api — not window.fetch. This keeps your tests decoupled from internal implementations.

One more thing: when using jest.mock with a factory function, be careful not to reference variables from the outer scope inside the factory — they won't be defined because the factory runs before imports. Use jest.requireActual to mix real and mocked exports if needed.

There's also a gotcha with named exports: if you mock a module that has both default and named exports, you need to use jest.mock with a factory that returns an object with __esModule: true and the exports. Otherwise, default import returns undefined.

Another pitfall: mocking a module that re-exports from another module (like an index.js with export * from './api'). Mocking the index.js doesn't mock the underlying api.js — the real network call leaks through. Always mock the deepest module that actually makes the call, or use a manual mock that covers all re-exports.

import { api } from './api';
import Analytics from '@segment/analytics-next';

// Full module mock
jest.mock('./api', () => ({
  fetchUser: jest.fn(() => Promise.resolve({ id: 1 })),
  fetchPosts: jest.fn(() => Promise.resolve([])),
}));

// Partial mock with spy
jest.mock('@segment/analytics-next');

beforeEach(() => {
  jest.clearAllMocks();
});

test('spyOn preserves original behavior', () => {
  const spy = jest.spyOn(console, 'log').mockImplementation(() => {});
  console.log('test');
  expect(spy).toHaveBeenCalledWith('test');
  spy.mockRestore();
});

test('analytics track is called on login', () => {
  const mockTrack = jest.fn();
  Analytics.mockImplementation(() => ({ track: mockTrack }));
  render(<LoginPage />);
  fireEvent.click(screen.getByText('Log in'));
  expect(mockTrack).toHaveBeenCalledWith('Login', expect.any(Object));
});

The act() Warning — What It Means and How to Fix It

React's act() warning appears when state updates happen outside of a simulated user interaction. This usually happens in three scenarios:

1. Asynchronous effects: A component's useEffect triggers a state update after a promise resolves. If you don't wait for that promise to resolve, the update happens outside act.
2. Timers: setTimeout, setInterval, or animation frames cause state updates after the test ends.
3. External event listeners: Event listeners (e.g., scroll, resize) that fire during the test's lifecycle.

To fix: wrap the trigger in await act(async () => { ... }) or use waitFor which internally uses act. RTL's userEvent is already wrapped in act. But fireEvent is not — you must wrap it yourself.

The warning is not just cosmetic. It indicates that your test may miss a render, causing false positives. In production, that missed render could be a critical UI update that your test didn't verify.

Here's a pattern that trips up even senior devs: when you have a setInterval in a component, the timer fires after the test finishes. Without fake timers, that update fires outside act and you get the warning. Use jest.useFakeTimers and advance time inside act.

Another advanced case: a useEffect that subscribes to a browser event like resize. The event listener fires outside act when you simulate a resize. The fix is to fire the resize event inside act() after rendering: act(() => { window.dispatchEvent(new Event('resize')) }). This ensures the state update from the resize is flushed before your assertion.

import { render, screen, waitFor, act } from '@testing-library/react';
import TimerComponent from './TimerComponent';

// ❌ Wrong: setInterval updates after test ends
// test('displays count', () => {
//   render(<TimerComponent />);
//   // act() warning appears
// });

// ✅ Correct: use jest.useFakeTimers
beforeEach(() => {
  jest.useFakeTimers();
});

test('displays count after timer fires', async () => {
  render(<TimerComponent />);
  act(() => { jest.advanceTimersByTime(1000); });
  await waitFor(() => {
    expect(screen.getByText('1')).toBeInTheDocument();
  });
});

afterEach(() => {
  jest.useRealTimers();
});

// ✅ Correct: wrapping promise resolution
test('resolves promise inside act', async () => {
  const promise = Promise.resolve();
  render(<AsyncComponent />);
  await act(async () => {
    await promise;
  });
  // assertions after act
});

Testing Custom Hooks with renderHook

Custom hooks contain logic that may need to be tested independently of any component. React Testing Library's renderHook creates a test harness that calls your hook and re-renders when its dependencies change.

renderHook returns a result object with a current property that reflects the latest return value of the hook. You can also use rerender with new props to test how the hook responds to prop changes.

This is especially useful for hooks that manage state, side effects, or combine multiple hooks. By isolating the hook, you write simpler, faster tests with fewer dependencies.

One nuance: if your hook uses useContext, you need to pass a wrapper component that provides the context. The wrapper option on renderHook does exactly that — it wraps the hook's component in a provider.

Another gotcha: hooks that use useState and useEffect together require careful sequencing. The effect runs after the initial render, so you must wait for it. Use waitFor on result.current to wait for the async update.

There's also a subtlety with rerender: if you pass the same props, the effect won't re-run unless the dependency array includes those props. That's expected React behavior—your test should match the real lifecycle.

import { renderHook, act } from '@testing-library/react';
import useCounter from './useCounter';

test('should increment counter', () => {
  const { result } = renderHook(() => useCounter());

  act(() => {
    result.current.increment();
  });

  expect(result.current.count).toBe(1);
});

test('should accept initial value', () => {
  const { result, rerender } = renderHook(
    (props) => useCounter(props.initial),
    { initialProps: { initial: 10 } }
  );

  expect(result.current.count).toBe(10);

  rerender({ initial: 20 });
  // hook should ignore subsequent initial changes (if designed that way)
});

test('async hook with useEffect', async () => {
  jest.useFakeTimers();
  const { result } = renderHook(() => useAsyncData());
  
  expect(result.current.data).toBeNull();
  
  act(() => { jest.advanceTimersByTime(1000); });
  
  await waitFor(() => {
    expect(result.current.data).toEqual({ id: 1 });
  });
});

Testing Components That Depend on React Context

Many components rely on context for theme, authentication, or localization. When testing these components, you can't just render them — you need to wrap them in a provider that supplies the context value. RTL's render function accepts a wrapper option that lets you do this cleanly.

Create a custom wrapper component that includes all providers your component needs. Then pass it to every test that requires context. This keeps your tests DRY and makes the context explicit.

Here's an example: testing a button that uses a theme context to pick its background colour.

If you have multiple contexts, compose them in a single wrapper. For example, AuthProvider nested inside ThemeProvider. A shared AllTheProviders component in a test-utils file avoids duplication across test suites.

A common pitfall: forgetting to provide a context leads to undefined values, which may cause the component to render null silently. The test passes because it doesn't assert on the missing element. Always assert that the component actually rendered something meaningful when context is involved.

import { render, screen } from '@testing-library/react';
import { ThemeContext, themes } from './ThemeContext';
import ThemedButton from './ThemedButton';

const renderWithTheme = (component, theme = themes.light) => {
  return render(
    <ThemeContext.Provider value={theme}>
      {component}
    </ThemeContext.Provider>
  );
};

test('renders button with light theme background', () => {
  renderWithTheme(<ThemedButton>Click me</ThemedButton>);
  const button = screen.getByText('Click me');
  expect(button).toHaveStyle({ backgroundColor: themes.light.background });
});

test('renders button with dark theme background', () => {
  renderWithTheme(<ThemedButton>Click me</ThemedButton>, themes.dark);
  const button = screen.getByText('Click me');
  expect(button).toHaveStyle({ backgroundColor: themes.dark.background });
});

// Shared util pattern — place in test-utils.jsx
export const AllTheProviders = ({ children, theme = themes.light }) => (
  <ThemeContext.Provider value={theme}>
    <AuthContext.Provider value={{ user: { id: 1 } }}>
      {children}
    </AuthContext.Provider>
  </ThemeContext.Provider>
);

export const customRender = (ui, options) =>
  render(ui, { wrapper: AllTheProviders, ...options });

Using MSW for Integration Testing

Mock Service Worker (MSW) is an API mocking library that intercepts network requests at the service worker level. Unlike jest.mock, which replaces module imports, MSW works at the network layer — it intercepts fetch and XMLHttpRequest calls globally. This makes it ideal for integration tests where you want realistic request/response handling without hitting real servers.

MSW runs in both Node.js (for Jest) and browser environments. You define handlers that match specific URLs and return responses. The handlers are reusable across tests and can be scoped per test using server.use().

Why use MSW over jest.mock? It catches network issues that module-level mocks miss — like incorrect request bodies, headers, or status codes. It also works with third-party libraries that make their own network calls.

One pitfall: MSW intercepts at the network level, so if you have a module that does some processing before calling fetch (like serializing query parameters), MSW will see the actual URL and headers. This is great for catching serialization bugs.

Another advantage: MSW handlers can be shared between different test frameworks. You can use the same handlers in Jest unit tests and Playwright end-to-end tests, ensuring consistency across your test pyramid.

import { render, screen, waitFor } from '@testing-library/react';
import { rest } from 'msw';
import { setupServer } from 'msw/node';
import UserList from './UserList';

const server = setupServer(
  rest.get('/api/users', (req, res, ctx) => {
    return res(ctx.json([{ id: 1, name: 'Alice' }]));
  })
);

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

test('displays users from API', async () => {
  render(<UserList />);

  await waitFor(() => {
    expect(screen.getByText('Alice')).toBeInTheDocument();
  });
});

test('shows error when API fails', async () => {
  server.use(
    rest.get('/api/users', (req, res, ctx) => {
      return res(ctx.status(500));
    })
  );

  render(<UserList />);

  await waitFor(() => {
    expect(screen.getByText(/error/i)).toBeInTheDocument();
  });
});

// Custom handler for specific request body
test('sends correct request body', async () => {
  let capturedBody;
  server.use(
    rest.post('/api/users', async (req, res, ctx) => {
      capturedBody = await req.json();
      return res(ctx.status(201));
    })
  );
  
  render(<UserForm />);
  fireEvent.click(screen.getByText('Submit'));
  
  await waitFor(() => {
    expect(capturedBody).toEqual({ name: 'Alice' });
  });
});

Production Debugging — Identifying Slow and Flaky Tests

A test suite that passes unpredictably or takes 10 minutes is a liability, not a safety net. Two common issues are flaky tests (intermittent failures) and slow tests (excessive runtime).

Jest provides profiling tools. Run jest --verbose --silent to see times per test. Use test.concurrent for independent tests that can run in parallel. Run slow tests in isolation with jest --testPathPattern=<pattern>.

One more tool: jest --detectOpenHandles finds unhandled promises or open connections that keep the test runner hanging. If your suite never terminates, run this to find the culprit.

Another approach: tag slow tests with a @slow custom test modifier and exclude them from the CI fast feedback loop. Run them in a separate nightly pipeline.

Pro tip: set up a threshold in CI. If the test suite takes more than 5 minutes, fail the build. This enforces discipline around test performance.

# Find test files that take more than 1 second
jest --verbose --silent | grep -E '✓|✕' | awk '{print $NF}' | sort -rn | head -20

# Run tests with a performance report
jest --detectOpenHandles --logHeapUsage --verbose 2>&1 | tee test-perf.log

# Profile specific test file
jest --no-cache --runInBand my-slow-test.test.js

# Find flaky tests by running 10 times
for i in $(seq 10); do jest --testPathPattern=flaky.test.js --bail; done

# Run only changed tests (CI optimization)
jest --onlyChanged --testPathPattern='src/'

# Show slowest tests after run
jest --verbose --silent --json --outputFile=test-results.json
cat test-results.json | jq '.testResults[].perfStats.runtime' | sort -rn | head -10

Frequently Asked Questions