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

Concept Flow - Unit testing services

Write test case

↓

Create testing module

↓

Inject service

↓

Call service method

↓

Check result with expect()

↓

Pass or fail test

↓

Repeat for other methods

This flow shows how to write and run a unit test for a NestJS service step-by-step.

Execution Sample

NestJS

describe('CatsService', () => {
  let service: CatsService;

  beforeEach(async () => {
    const module = await Test.createTestingModule({ providers: [CatsService] }).compile();
    service = module.get<CatsService>(CatsService);
  });

  it('should return all cats', () => {
    expect(service.findAll()).toEqual(['cat1', 'cat2']);
  });
});

This code sets up a test for CatsService and checks if findAll() returns the expected list.

Execution Table

Step	Action	Evaluation	Result
1	Create testing module with CatsService	Module created	Module instance ready
2	Get CatsService instance from module	Service injected	service variable assigned
3	Call service.findAll()	Returns ['cat1', 'cat2']	Output: ['cat1', 'cat2']
4	Compare output with expect()	Output matches expected	Test passes
5	End of test case	No more tests	Test suite completes

💡 All test cases executed, no failures

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
service	undefined	CatsService instance	CatsService instance	CatsService instance
output	undefined	undefined	['cat1', 'cat2']	['cat1', 'cat2']

Key Moments - 3 Insights

Why do we create a testing module before getting the service?

The testing module simulates NestJS dependency injection, so the service can be properly created and injected as in the real app. See Step 1 and 2 in execution_table.

What does expect(service.findAll()).toEqual(...) check?

It checks if the service method returns exactly the expected value. If it matches, the test passes (Step 4).

Why do we use beforeEach() to create the module and service?

beforeEach() runs before every test to ensure a fresh service instance, avoiding shared state between tests. This keeps tests independent.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'service' after Step 2?

A null

B CatsService instance

C undefined

D Array of cats

💡 Hint

Check the 'service' variable in variable_tracker after Step 2

At which step does the test check if the output matches the expected value?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Action' and 'Result' columns in execution_table for the expect() call

If the service.findAll() returned ['cat1'] instead of ['cat1', 'cat2'], what would happen at Step 4?

A Test fails

B Test passes

C Service instance changes

D Module creation fails

💡 Hint

Step 4 compares output with expected value; mismatch causes failure

Concept Snapshot

Unit testing services in NestJS:
- Use Test.createTestingModule to build a test module
- Inject service with module.get()
- Call service methods inside it() blocks
- Use expect() to check outputs
- Use beforeEach() for fresh setup
- Tests pass if outputs match expected values

Full Transcript

Unit testing services in NestJS involves creating a testing module that mimics the real app environment. We inject the service we want to test from this module. Then, we call the service methods and check their outputs using expect(). The beforeEach() function ensures each test runs with a fresh service instance. If the output matches what we expect, the test passes. This process helps us verify that our service behaves correctly in isolation.

Practice

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

easy

A. To verify the service works correctly on its own without dependencies

B. To test the entire application including all modules

C. To check the UI components connected to the service

D. To deploy the service to production automatically

Solution

1. Step 1: Understand unit testing scope

   Unit testing focuses on testing a single piece of code in isolation, here the service alone.

2. Step 2: Identify what unit testing excludes

   It excludes integration with other modules or UI, focusing only on the service logic.

3. Final Answer:

   To verify the service works correctly on its own without dependencies -> Option A

4. Quick Check:

   Unit testing = isolated service check [OK]

Hint: Unit test means testing one piece alone, no dependencies [OK]

Common Mistakes:

• Confusing unit test with integration test
• Thinking unit test covers UI or deployment
• Assuming unit test runs the whole app

2. Which of the following is the correct way to get a service instance in a NestJS unit test?

easy

A. const service = require('MyService');

B. const service = new MyService();

C. const service = module.get<MyService>(MyService);

D. const service = app.getService(MyService);

Solution

1. Step 1: Use NestJS TestingModule

   In unit tests, you create a TestingModule and get the service instance via module.get.

2. Step 2: Identify correct syntax

   The syntax module.get<MyService>(MyService) is the official way to retrieve the service from the test module.

3. Final Answer:

   const service = module.get<MyService>(MyService); -> Option C

4. Quick Check:

   Use module.get to get service instance [OK]

Hint: Always get service from TestingModule with module.get<Type>(Type) [OK]

Common Mistakes:

• Instantiating service directly without module
• Using app.getService which is not a NestJS method
• Using require which is not for NestJS DI

3. Given this test code snippet, what will be the output of service.getData()?

const mockData = ['a', 'b'];
const mockRepo = { findAll: () => mockData };

const module = await Test.createTestingModule({
  providers: [
    MyService,
    { provide: MyRepository, useValue: mockRepo },
  ],
}).compile();

const service = module.get<MyService>(MyService);

console.log(service.getData());

medium

A. An error because MyRepository is not mocked

B. undefined

C. [] (empty array)

D. ['a', 'b']

Solution

1. Step 1: Understand mocking of MyRepository

   The mockRepo object replaces MyRepository with a findAll method returning ['a', 'b'].

2. Step 2: Analyze service.getData()

   Assuming getData calls repository.findAll(), it will return ['a', 'b'] from the mock.

3. Final Answer:

   ['a', 'b'] -> Option D

4. Quick Check:

   Mocked repo returns ['a', 'b'] so service returns same [OK]

Hint: Mocked methods return mock values used by service [OK]

Common Mistakes:

• Forgetting to mock repository causing undefined
• Expecting real database call instead of mock
• Assuming empty array without mock data

4. What is the main issue in this test setup code?

const module = await Test.createTestingModule({
  providers: [MyService],
}).compile();

const service = module.get<MyService>(MyService);

jest.spyOn(service, 'findAll').mockReturnValue(['x', 'y']);

medium

A. You cannot spy on service methods before mocking dependencies

B. The service method findAll should be mocked on the dependency, not service

C. jest.spyOn syntax is incorrect here

D. Missing async keyword on test function

Solution

1. Step 1: Identify what to mock in unit tests

   In unit tests, you mock dependencies of the service, not the service's own methods.

2. Step 2: Understand why mocking service method is wrong

   Mocking service.findAll replaces the method under test, defeating the purpose of testing it.

3. Final Answer:

   The service method findAll should be mocked on the dependency, not service -> Option B

4. Quick Check:

   Mock dependencies, not the service itself [OK]

Hint: Mock dependencies, never the service method you test [OK]

Common Mistakes:

• Mocking the service method instead of its dependencies
• Confusing spyOn usage with mocking dependencies
• Ignoring async test function requirements

5. You want to test a service method that calls two different repository methods internally. How should you set up your unit test to isolate the service logic correctly?

hard

A. Mock both repository methods with expected return values and inject them into the test module

B. Call the real repository methods to test the full flow

C. Mock only one repository method and leave the other real

D. Do not mock anything and test the service directly

Solution

1. Step 1: Identify dependencies to mock

   Since the service calls two repository methods, both should be mocked to isolate service logic.

2. Step 2: Setup test module with mocks

   Provide mock implementations for both methods in the test module providers to control their outputs.

3. Step 3: Avoid real calls in unit tests

   Calling real repository methods would make it an integration test, not a unit test.

4. Final Answer:

   Mock both repository methods with expected return values and inject them into the test module -> Option A

5. Quick Check:

   Mock all dependencies to isolate service logic [OK]

Hint: Mock all called dependencies to isolate service logic [OK]

Common Mistakes:

• Mocking only some dependencies causing partial isolation
• Calling real methods making it integration test
• Not injecting mocks properly into test module