Integration testing in NestJS - Performance & Optimization

Performance: Integration testing

MEDIUM IMPACT

Integration testing affects development and CI pipeline speed, impacting how quickly changes can be verified and deployed.

Running integration tests for NestJS services and controllers

NestJS

beforeAll(async () => {
  const moduleRef = await Test.createTestingModule({
    imports: [SpecificModule],
  }).compile();
  app = moduleRef.createNestApplication();
  await app.init();
});

Only load necessary modules once per test suite, reducing initialization overhead.

📈 Performance GainReduces setup time by 70-80%, speeding up test runs and CI feedback.

Running integration tests for NestJS services and controllers

NestJS

beforeEach(async () => {
  const moduleRef = await Test.createTestingModule({
    imports: [AppModule],
  }).compile();
  app = moduleRef.createNestApplication();
  await app.init();
});

Bootstrapping the entire application module for every test causes slow startup and redundant resource usage.

📉 Performance CostBlocks test execution for 500ms+ per test suite, increasing total CI time significantly.

Performance Comparison

Pattern	Test Initialization Time	Resource Usage	Parallelizability	Verdict
Full AppModule per test	High (500ms+)	High (DB, services)	Low	[X] Bad
Specific Module once per suite	Low (100ms)	Low	High	[OK] Good

Rendering Pipeline

Integration testing runs outside the browser rendering pipeline but impacts developer productivity and deployment speed by affecting test execution time.

→Test Initialization

→Dependency Injection Setup

→Database Connections

⚠️ BottleneckTest Initialization and full app bootstrapping

Optimization Tips

1Avoid full app bootstrapping before every test to reduce slowdowns.

2Reuse initialized app instances across tests when possible.

3Mock external services to prevent slow network or DB calls.

Performance Quiz - 3 Questions

What is the main performance drawback of bootstrapping the entire NestJS app module before each integration test?

A It causes slow test startup and increases total test suite runtime.

B It reduces test coverage by limiting modules.

C It improves test isolation but uses more memory.

D It speeds up tests by caching dependencies.

DevTools: Node.js Profiler or Jest --runInBand with --detectOpenHandles

How to check: Run tests with profiling enabled or in single-thread mode to measure setup time and resource leaks.

What to look for: Long setup times, open handles, or repeated full app initialization indicate performance issues.