Unit testing controllers in NestJS - Step-by-Step Execution

Concept Flow - Unit testing controllers

Write test case

↓

Setup testing module

↓

Inject controller

↓

Mock dependencies

↓

Call controller method

↓

Assert expected result

↓

Test passes or fails

This flow shows how a unit test for a NestJS controller is written, setting up the test module, injecting the controller, mocking dependencies, calling methods, and checking results.

Execution Sample

NestJS

describe('CatsController', () => {
  let controller: CatsController;

  const mockCatsService = {
    findAll: jest.fn(),
  };

  beforeEach(async () => {
    const module = await Test.createTestingModule({
      controllers: [CatsController],
      providers: [{ provide: CatsService, useValue: mockCatsService }],
    }).compile();

    controller = module.get<CatsController>(CatsController);
  });

  it('should return all cats', async () => {
    jest.spyOn(mockCatsService, 'findAll').mockResolvedValue(['cat1', 'cat2']);
    const result = await controller.findAll();
    expect(result).toEqual(['cat1', 'cat2']);
  });
});

This test sets up a NestJS testing module, injects the CatsController with a mocked CatsService, calls the findAll method, and checks the returned cats.

Execution Table

Step	Action	Evaluation	Result
1	Create testing module with CatsController and mockCatsService	Module created	Testing module ready
2	Get CatsController instance from module	Controller injected	controller variable assigned
3	Mock CatsService.findAll to return ['cat1', 'cat2']	Mock applied	findAll returns ['cat1', 'cat2']
4	Call controller.findAll()	Calls mocked service	Returns ['cat1', 'cat2']
5	Assert result equals ['cat1', 'cat2']	Check equality	Test passes

💡 Test completes after assertion; passes if result matches expected array

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
controller	undefined	CatsController instance	CatsController instance with mocked service	Result of findAll call pending	Result is ['cat1', 'cat2']
mockCatsService.findAll	undefined	undefined	Mocked to return ['cat1', 'cat2']	Returns ['cat1', 'cat2']	Returns ['cat1', 'cat2']

Key Moments - 3 Insights

Why do we mock the service instead of using the real one?

We mock the service to isolate the controller's behavior and avoid dependencies on external data or logic, as shown in step 3 of the execution_table.

How does the controller get the mocked service?

The mocked service is provided in the testing module setup (step 1), so when the controller is injected (step 2), it uses the mock instead of the real service.

What happens if the controller method returns a different result than expected?

The assertion in step 5 will fail, causing the test to fail, indicating a problem in the controller or mock setup.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'controller' after step 2?

A MockCatsService instance

B CatsController instance

C undefined

D Array of cats

💡 Hint

Check the variable_tracker row for 'controller' after Step 2

At which step is the CatsService.findAll method mocked?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Look at the 'Action' column in execution_table for mocking

If the mock returned an empty array instead of ['cat1', 'cat2'], what would change in the execution_table?

A Step 5 assertion would pass

B Step 3 would fail

C Step 4 result would be [] instead of ['cat1', 'cat2']

D Controller would not be injected

💡 Hint

Check the 'Result' column for Step 4 and how it affects the assertion in Step 5

Concept Snapshot

Unit testing controllers in NestJS:
- Use Test.createTestingModule to set up test environment
- Provide controller and mock dependencies
- Inject controller instance
- Mock service methods with jest.spyOn
- Call controller methods and assert results
- Isolate controller logic from real services

Full Transcript

Unit testing controllers in NestJS involves creating a testing module that includes the controller and mocks of its dependencies. The controller is injected from this module. Service methods are mocked to control their output. The controller method is called, and its output is checked against expected results. This isolates the controller's logic and ensures it behaves correctly without relying on real services or databases.

Practice

1. What is the main purpose of unit testing a controller in NestJS?

easy

A. To verify the controller handles requests correctly without depending on other parts

B. To test the database connection and queries

C. To check the UI rendering of the application

D. To measure the performance of the entire application

Solution

1. Step 1: Understand the role of a controller

   Controllers handle incoming requests and return responses, so testing them focuses on this behavior.

2. Step 2: Identify what unit testing isolates

   Unit testing isolates the controller from other parts like services or databases to test its logic alone.

3. Final Answer:

   To verify the controller handles requests correctly without depending on other parts -> Option A

4. Quick Check:

   Unit testing controller logic = To verify the controller handles requests correctly without depending on other parts [OK]

Hint: Controllers handle requests; test them isolated from services [OK]

Common Mistakes:

• Confusing unit tests with integration tests
• Testing database or UI in controller unit tests
• Ignoring mocking dependencies

2. Which of the following is the correct way to create a testing module for a controller in NestJS?

easy

A. const module = Test.createModule({ providers: [MyController] });

B. const module = new Module({ controllers: [MyController] });

C. const module = await Test.createTestingModule({ controllers: [MyController] }).compile();

D. const module = await Test.createTestingModule({ services: [MyController] }).compile();

Solution

1. Step 1: Recall NestJS testing syntax

   Use Test.createTestingModule with a config object specifying controllers or providers, then compile it.

2. Step 2: Identify correct property for controllers

   The property to register controllers is 'controllers', not 'services' or 'providers' for controllers.

3. Final Answer:

   const module = await Test.createTestingModule({ controllers: [MyController] }).compile(); -> Option C

4. Quick Check:

   Use controllers array in createTestingModule = const module = await Test.createTestingModule({ controllers: [MyController] }).compile(); [OK]

Hint: Use controllers: [] inside Test.createTestingModule [OK]

Common Mistakes:

• Using 'services' instead of 'controllers' key
• Forgetting to await compile()
• Using new Module() instead of Test.createTestingModule

3. Given this controller method and test snippet, what will result be?

class MyController {
  getHello() {
    return 'Hello World!';
  }
}

// Test snippet
const controller = new MyController();
const result = controller.getHello();

medium

A. null

B. undefined

C. An error because getHello is async

D. 'Hello World!'

Solution

1. Step 1: Analyze the controller method

   The method getHello returns the string 'Hello World!' synchronously.

2. Step 2: Check the test call

   Calling getHello() directly returns the string without errors or async behavior.

3. Final Answer:

   'Hello World!' -> Option D

4. Quick Check:

   Direct method call returns string = 'Hello World!' [OK]

Hint: Direct call returns method's return value immediately [OK]

Common Mistakes:

• Assuming async behavior without async keyword
• Expecting undefined if not mocked
• Confusing method call with property access

4. What is wrong with this unit test for a NestJS controller?

describe('MyController', () => {
  let controller: MyController;

  beforeEach(() => {
    controller = new MyController();
  });

  it('should return greeting', () => {
    expect(controller.getHello()).toBe('Hello World!');
  });
});

medium

A. The controller is not created using Test.createTestingModule

B. The test does not mock the service dependency

C. The test is missing async keyword

D. The expect statement uses toBe instead of toEqual

Solution

1. Step 1: Check controller instantiation

   Creating controller directly is allowed but only if it has no dependencies.

2. Step 2: Identify missing mocking

   If the controller depends on a service, it must be mocked to isolate controller logic.

3. Final Answer:

   The test does not mock the service dependency -> Option B

4. Quick Check:

   Missing mocks for dependencies = The test does not mock the service dependency [OK]

Hint: Always mock services when testing controllers with dependencies [OK]

Common Mistakes:

• Assuming direct instantiation is always wrong
• Forgetting to mock injected services
• Confusing toBe and toEqual for strings

5. You want to unit test a NestJS controller method that calls a service method returning a promise. Which approach correctly mocks the service to test the controller method synchronously?

hard

A. Mock the service method with jest.fn().mockResolvedValue(value) and await the controller method in the test

B. Mock the service method with jest.fn().mockReturnValue(value) without async/await

C. Call the real service method without mocking to test actual behavior

D. Mock the service method with jest.fn().mockImplementation(() => { throw new Error(); })

Solution

1. Step 1: Understand async service method

   The service method returns a promise, so the mock must simulate a resolved promise.

2. Step 2: Use jest.fn().mockResolvedValue

   This creates a mock that returns a resolved promise with the given value, allowing the controller method to await it.

3. Step 3: Await controller method in test

   The test must await the controller method to handle the async call properly.

4. Final Answer:

   Mock the service method with jest.fn().mockResolvedValue(value) and await the controller method in the test -> Option A

5. Quick Check:

   Use mockResolvedValue and await async calls = Mock the service method with jest.fn().mockResolvedValue(value) and await the controller method in the test [OK]

Hint: Use mockResolvedValue for async mocks and await calls [OK]

Common Mistakes:

• Using mockReturnValue for async methods
• Not awaiting async controller methods
• Testing real service instead of mocking