Unit testing providers with the testing module

The testing module is a throwaway DI container

When you see a nine-minute “unit” suite, ask yourself: what does it actually need a database for? Usually nothing — and the testing module is how you get that time back.

Test.createTestingModule({ providers: [...] }) builds a fresh, isolated Nest dependency-injection container that contains only what you list. Calling .compile() resolves the graph and hands you a TestingModule; module.get(Token) pulls a singleton instance out of it — your unit under test, already wired. Because you control the providers array, you decide exactly which dependencies are real and which are doubles. List the service under test as a real class, and supply every dependency it injects as a mock.

The cleanest way to supply a mock is a custom provider with useValue: same injection token, fake implementation. A jest.fn() per method gives you a spy you can program and assert against.

import { Test, TestingModule } from '@nestjs/testing';
import { getRepositoryToken } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { UsersService } from './users.service';
import { User } from './user.entity';

describe('UsersService', () => {
  let service: UsersService;
  let repo: jest.Mocked<Repository<User>>;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        UsersService, // real — this is the unit under test
        {
          provide: getRepositoryToken(User), // the token Nest injects for @InjectRepository(User)
          useValue: {
            findOne: jest.fn(),
            create: jest.fn((dto) => dto),
            save: jest.fn(),
          },
        },
      ],
    }).compile();

    service = module.get(UsersService);
    repo = module.get(getRepositoryToken(User));
  });

  it('rejects a duplicate email without saving', async () => {
    repo.findOne.mockResolvedValue({ id: 1, email: 'a@b.io' } as User);

    await expect(service.register({ email: 'a@b.io', password: 'pw' }))
      .rejects.toThrow('email already in use');

    expect(repo.save).not.toHaveBeenCalled(); // behavior, not implementation detail
  });

  it('saves a new user exactly once', async () => {
    repo.findOne.mockResolvedValue(null);
    repo.save.mockResolvedValue({ id: 7, email: 'new@b.io' } as User);

    const result = await service.register({ email: 'new@b.io', password: 'pw' });

    expect(repo.save).toHaveBeenCalledTimes(1);
    expect(repo.save).toHaveBeenCalledWith(
      expect.objectContaining({ email: 'new@b.io' }),
    );
    expect(result.id).toBe(7);
  });
});

Two details earn their keep. The token for a TypeORM repository is not the entity class — it’s getRepositoryToken(User), the synthetic token @InjectRepository(User) resolves to. Provide a value for that token and the service gets your mock. And the assertions check behavior: “didn’t save on a duplicate”, “saved once with this email”. They never reach into the service’s private fields. Tests coupled to behavior survive refactors; tests coupled to implementation break the moment you rename a variable.

Mock at the boundary, and only there

The same pattern covers any external collaborator. A JwtService, an HTTP client wrapping a payment API, a mailer — each is a seam between your logic and the outside world, and each gets a useValue double keyed by its token. What you do not mock is the thing under test (you’d be testing nothing) or pure internal helpers like a value object or a password-strength function — mocking those just freezes the implementation in place and tests your mock instead of your code. Mock the I/O boundary; let the logic run.

For a service that talks to both a repository and an external client, that’s two doubles:

const module = await Test.createTestingModule({
  providers: [
    OrdersService,
    { provide: getRepositoryToken(Order), useValue: { findOne: jest.fn(), save: jest.fn() } },
    { provide: PaymentClient, useValue: { charge: jest.fn().mockResolvedValue({ ok: true }) } },
  ],
}).compile();

Now OrdersService.checkout can be driven through every branch — payment declines, repository conflicts, happy path — in milliseconds, deterministically, with no network and no DB.

overrideProvider when the module is real

useValue works when you assemble the providers yourself. Sometimes you’d rather import the real feature module — to keep its wiring honest — and swap out just the leaf dependencies. That’s overrideProvider(TOKEN):

const module = await Test.createTestingModule({
  imports: [UsersModule], // the real module, real wiring
})
  .overrideProvider(getRepositoryToken(User))
  .useValue({ findOne: jest.fn(), save: jest.fn() })
  .compile();

After .useValue(...), you can instead chain .useClass(FakeRepo) (a stub class Nest instantiates with its own deps) or .useFactory({ factory: () => mock }) (when the double needs construction logic). And if you’d rather not name every double, .useMocker((token) => ...) auto-stubs everything not explicitly provided — handy for a service with a long dependency list, where you only care about one or two collaborators and want the rest to be inert no-op mocks.

Two ways to supply a dependency, side by side