Articles

Find and Fix Slow Jest Tests That Bloat Your CI Time (2026)

April 18, 2026 7 min read

Jest tests are crawling, and your CI pipeline is a snail. This isn’t just about a few slow tests; it’s about the cascading effect of accumulated overhead that turns a quick feedback loop into a glacial crawl, impacting developer velocity and increasing the cost of your CI infrastructure.

Let’s look at what a slow test actually means and how to surgically address it.

The Usual Suspects: Finding the Bottlenecks

1. Excessive Setup/Teardown Overhead

  • Diagnosis: Use Jest’s --runInBand flag to serialize test execution and observe which tests take disproportionately long before any actual assertions.
    npm test -- --runInBand --verbose # or yarn test --runInBand --verbose
    Look for tests with long beforeAll, beforeEach, afterAll, or afterEach blocks.
  • Cause: Repeatedly creating expensive resources (database connections, API clients, large data structures, complex component trees) within beforeEach or beforeAll that could be shared or initialized more efficiently.
  • Fix: Move resource initialization to beforeAll if it can be shared across all tests in a file, or consider using a shared mock/stub that doesn’t require full instantiation. For example, if a beforeEach creates a new new DatabaseService(), and it’s only used for its interface, mock it instead.
    // Bad: Inefficient beforeEach
describe('User API', () => {
  let userService;
  beforeEach(() => {
    userService = new UserService(new ApiClient('http://localhost:3000')); // Expensive
  });
  test('should fetch users', () => { /* ... */ });
});

// Good: Efficient beforeAll (if possible) or mock
describe('User API', () => {
  let userService;
  beforeAll(() => {
    // If UserService can be initialized once and reused
    userService = new UserService(new ApiClient('http://localhost:3000'));
  });
  test('should fetch users', () => { /* ... */ });
});

// Better: Mocking if only the interface is needed
describe('User API', () => {
  test('should fetch users', async () => {
    const mockApiClient = { get: jest.fn().mockResolvedValue([{ id: 1, name: 'Test' }]) };
    const userService = new UserService(mockApiClient);
    const users = await userService.getUsers();
    expect(users).toEqual([{ id: 1, name: 'Test' }]);
    expect(mockApiClient.get).toHaveBeenCalledWith('/users');
  });
});
  • Why it works: Reduces redundant work. beforeAll runs once per file, and mocking bypasses costly external dependencies or complex internal logic entirely.

2. Unnecessary Real Network Requests / External API Calls

  • Diagnosis: Use Jest’s --verbose flag and look for tests that mention network activity or external services. Analyze your test code for fetch, axios, or custom HTTP client calls.
  • Cause: Tests that hit actual network endpoints instead of using mocks or stubs. This introduces latency from network hops, server response times, and potential network instability.
  • Fix: Implement mocks for your HTTP clients or use libraries like msw (Mock Service Worker) or jest-mock-extended. Configure your HTTP client to use a mock adapter during tests.
    // Using axios with a mock adapter
import axios from 'axios';
import MockAdapter from 'axios-mock-adapter';

const mock = new MockAdapter(axios);

mock.onGet('/users/1').reply(200, {
  id: 1,
  name: 'John Doe',
});

test('should fetch user 1', async () => {
  const response = await axios.get('/users/1');
  expect(response.data).toEqual({ id: 1, name: 'John Doe' });
});
  • Why it works: Replaces slow, unreliable network I/O with in-memory data retrieval, which is orders of magnitude faster and deterministic.

3. Large or Inefficient Data Fixtures

  • Diagnosis: Examine the size of JSON files or JavaScript objects used as test data. If tests involve loading or processing large amounts of data, this is a prime suspect.
  • Cause: Loading gigabytes of data into memory for a simple unit test, or performing complex transformations on data within the test itself.
  • Fix:
    • Data Sharding/Subsetting: Load only the minimum necessary data for each test. If a test only needs 3 users, don’t load 1000.
    • Lazy Loading: If data is truly massive, consider loading it only when absolutely required by a specific test suite, not globally.
    • Data Generation: For complex or large datasets, consider using libraries like faker.js to generate data on the fly, but be mindful of generating too much data.
    // Example: Generating data instead of loading a huge file
import { faker } from '@faker-js/faker';

test('should process a small batch of records', () => {
  const records = Array.from({ length: 50 }, () => ({
    id: faker.datatype.uuid(),
    name: faker.name.fullName(),
    value: faker.datatype.number({ min: 100, max: 1000 }),
  }));
  // Process 'records'
  expect(/* ... */);
});
  • Why it works: Reduces the amount of data read from disk, parsed, and held in memory, speeding up initialization and processing.

4. Unnecessary Rendering of Complex Components (React/Vue/Angular)

  • Diagnosis: In component tests, observe the time spent in render or mount functions. Use Jest’s --verbose and profile individual test file execution times.
  • Cause: Rendering entire application trees or deeply nested components when only a small part of the UI or a specific prop/state interaction needs to be tested. This involves mounting many DOM nodes and running many lifecycle methods.
  • Fix:
    • Shallow Rendering/Component Stubbing: Use tools like react-testing-library’s render (which is not truly shallow but encourages testing behavior) or libraries that offer explicit shallow rendering. Mock child components to prevent their rendering.
    • Targeted Rendering: Only render the specific component under test and mock its children or provide minimal props.
    // React Testing Library example
import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';
import ChildComponent from './ChildComponent'; // Assume this is complex

// Mock the complex child component
jest.mock('./ChildComponent', () => () => <div data-testid="mock-child">Mocked Child</div>);

test('renders MyComponent with a mocked child', () => {
  render(<MyComponent />);
  expect(screen.getByText('My Component Content')).toBeInTheDocument();
  expect(screen.getByTestId('mock-child')).toBeInTheDocument();
});
  • Why it works: Drastically reduces the amount of DOM manipulation, JavaScript execution, and lifecycle hooks triggered, focusing the test on the unit it’s supposed to verify.

5. Inefficient State Management or Global Stores

  • Diagnosis: Identify tests that interact heavily with global state (e.g., Redux, Zustand, Vuex). Observe if state updates or selectors are slow.
  • Cause: Tests that trigger numerous state mutations, complex selectors that recompute frequently, or global stores that are not properly reset between tests.
  • Fix:
    • Reset State: Ensure your store is reset to a clean initial state before each test (beforeEach).
    • Mock Selectors/State: If a test doesn’t depend on the actual state logic, mock the selectors or the store itself to return predefined values.
    • Optimize Selectors: If selectors are genuinely slow, refactor them to be more efficient (e.g., using memoization libraries like reselect for Redux).
    // Example: Resetting a Zustand store
import create from 'zustand';

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

// In your test file:
describe('Counter', () => {
  beforeEach(() => {
    // Reset store to initial state before each test
    useStore.setState({ count: 0 }, true); // The 'true' forces an immediate update
  });

  test('increments count', () => {
    useStore.getState().increment();
    expect(useStore.getState().count).toBe(1);
  });
});
  • Why it works: Prevents state from leaking between tests and ensures tests start from a known, predictable baseline, avoiding the cost of complex state propagation or computation.

6. Using jest.useFakeTimers() Incorrectly or Not at All

  • Diagnosis: Tests involving setTimeout, setInterval, requestAnimationFrame, or any asynchronous operations that rely on time. If these tests are slow, it’s likely due to real-time execution.
  • Cause: Not advancing timers or advancing them manually one tick at a time when many operations are pending.
  • Fix: Use jest.useFakeTimers() in beforeEach or beforeAll and jest.useRealTimers() in afterEach or afterAll. Advance timers explicitly using jest.advanceTimersByTime(milliseconds) or jest.runAllTimers().
    describe('Debounced function', () => {
  jest.useFakeTimers(); // Enable fake timers

  test('debounced function should not be called immediately', () => {
    const func = jest.fn();
    const debouncedFunc = _.debounce(func, 100); // Using lodash debounce for example

    debouncedFunc();
    expect(func).not.toHaveBeenCalled();

    jest.advanceTimersByTime(99); // Advance time by 99ms
    expect(func).not.toHaveBeenCalled();

    jest.advanceTimersByTime(1); // Advance time by the remaining 1ms
    expect(func).toHaveBeenCalledTimes(1);
  });

  afterEach(() => {
    jest.useRealTimers(); // Restore real timers
  });
});
  • Why it works: Simulates the passage of time instantly, allowing asynchronous operations scheduled with timers to be executed deterministically and immediately without waiting for actual clock time.

When all these are fixed, the next thing that will likely slow you down is the sheer number of tests, leading you to explore parallelization, test splitting, or incremental testing strategies.

Want structured learning?

Take the full Jest course →