NestJS testing module

`@nestjs/testing` builds isolated application slices via `Test.createTestingModule()`. Override providers to inject mocks, compile the module, and retrieve services or HTTP adapters for assertions.

					const moduleRef = await Test.createTestingModule({
  controllers: [UsersController],
  providers: [
    UsersService,
    { provide: UsersRepository, useValue: mockRepo },
  ],
}).compile();

const controller = moduleRef.get(UsersController);
const service = moduleRef.get(UsersService);
				

E2E tests use `INestApplication` with `supertest` against `app.getHttpServer()`. Unit tests target services with mocked dependencies; integration tests compile feature modules with test doubles for IO.

On interviews: `overrideProvider` versus manual mocks, testing guards and pipes in isolation, and avoiding full `AppModule` in every test.

Common pitfalls: compiling the entire app per test (slow), not closing `app.close()`, and tests that hit real external services.

The trade-off is balancing simplicity, performance, safety, and operability — name which axis you optimized and what cost you accepted.

Checklist:

• Build minimal TestingModule per test scope.
• Override external IO at provider boundaries.
• Close Nest application after e2e tests.
• Test controllers with mocked services, not real DB.