- 1. API with NestJS #1. Controllers, routing and the module structure
- 2. API with NestJS #2. Setting up a PostgreSQL database with TypeORM
- 3. API with NestJS #3. Authenticating users with bcrypt, Passport, JWT, and cookies
- 4. API with NestJS #4. Error handling and data validation
- 5. API with NestJS #5. Serializing the response with interceptors
- 6. API with NestJS #6. Looking into dependency injection and modules
- 7. API with NestJS #7. Creating relationships with Postgres and TypeORM
- 8. API with NestJS #8. Writing unit tests
- 9. API with NestJS #9. Testing services and controllers with integration tests
- 10. API with NestJS #10. Uploading public files to Amazon S3
- 11. API with NestJS #11. Managing private files with Amazon S3
- 12. API with NestJS #12. Introduction to Elasticsearch
- 13. API with NestJS #13. Implementing refresh tokens using JWT
- 14. API with NestJS #14. Improving performance of our Postgres database with indexes
- 15. API with NestJS #15. Defining transactions with PostgreSQL and TypeORM
- 16. API with NestJS #16. Using the array data type with PostgreSQL and TypeORM
- 17. API with NestJS #17. Offset and keyset pagination with PostgreSQL and TypeORM
- 18. API with NestJS #18. Exploring the idea of microservices
- 19. API with NestJS #19. Using RabbitMQ to communicate with microservices
- 20. API with NestJS #20. Communicating with microservices using the gRPC framework
- 21. API with NestJS #21. An introduction to CQRS
- 22. API with NestJS #22. Storing JSON with PostgreSQL and TypeORM
- 23. API with NestJS #23. Implementing in-memory cache to increase the performance
- 24. API with NestJS #24. Cache with Redis. Running the app in a Node.js cluster
- 25. API with NestJS #25. Sending scheduled emails with cron and Nodemailer
- 26. API with NestJS #26. Real-time chat with WebSockets
- 27. API with NestJS #27. Introduction to GraphQL. Queries, mutations, and authentication
- 28. API with NestJS #28. Dealing in the N + 1 problem in GraphQL
- 29. API with NestJS #29. Real-time updates with GraphQL subscriptions
- 30. API with NestJS #30. Scalar types in GraphQL
- 31. API with NestJS #31. Two-factor authentication
- 32. API with NestJS #32. Introduction to Prisma with PostgreSQL
- 33. API with NestJS #33. Managing PostgreSQL relationships with Prisma
- 34. API with NestJS #34. Handling CPU-intensive tasks with queues
- 35. API with NestJS #35. Using server-side sessions instead of JSON Web Tokens
- 36. API with NestJS #36. Introduction to Stripe with React
- 37. API with NestJS #37. Using Stripe to save credit cards for future use
- 38. API with NestJS #38. Setting up recurring payments via subscriptions with Stripe
- 39. API with NestJS #39. Reacting to Stripe events with webhooks
- 40. API with NestJS #40. Confirming the email address
- 41. API with NestJS #42. Authenticating users with Google
- 42. API with NestJS #41. Verifying phone numbers and sending SMS messages with Twilio
Testing our application can increase our confidence when it comes to creating a fully-functional API. In this article, we look into how we can test our application by writing unit tests. We do so by using some of the utilities built into NestJS, as well as the Jest library.
If you would like to get to know Jest better first, check out the first part of the JavaScript testing tutorial.
Testing NestJS with unit tests
The job of a unit test is to verify an individual piece of code. A tested unit can be a module, a class, or a function. Each of our tests should be isolated and independent of each other. By writing unit tests, we can make sure that individual parts of our application work as expected.
Let’s write some tests for the AuthenticationService.
src/authentication/tests/authentication.service.spec.ts
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | import { AuthenticationService } from '../authentication.service'; import { UsersService } from '../../users/users.service'; import { Repository } from 'typeorm'; import User from '../../users/user.entity'; import { JwtService } from '@nestjs/jwt'; import { ConfigService } from '@nestjs/config'; describe('The AuthenticationService', () => { const authenticationService = new AuthenticationService( new UsersService( new Repository<User>() ), new JwtService({ secretOrPrivateKey: 'Secret key' }), new ConfigService() ); describe('when creating a cookie', () => { it('should return a string', () => { const userId = 1; expect( typeof authenticationService.getCookieWithJwtToken(userId) ).toEqual('string') }) }) }); |
PASS src/authentication/tests/authentication.service.spec.ts
The AuthenticationService
when creating a cookie
✓ should return a string (12ms)
When we execute npm run test, Jest looks for files ending with .spec.ts and executes them.
We can improve the above code. Each of our tests needs to be independent, and we need to ensure that. If we add more tests in the above file, all of them will use the same instance of the AuthenticationService. It breaks the rule of all tests being independent.
To deal with it, we can use the beforeEach that runs before every test.
src/authentication/tests/authentication.service.spec.ts
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | import { AuthenticationService } from '../authentication.service'; import { UsersService } from '../../users/users.service'; import { Repository } from 'typeorm'; import User from '../../users/user.entity'; import { JwtService } from '@nestjs/jwt'; import { ConfigService } from '@nestjs/config'; describe('The AuthenticationService', () => { let authenticationService: AuthenticationService; beforeEach(() => { authenticationService = new AuthenticationService( new UsersService( new Repository<User>() ), new JwtService({ secretOrPrivateKey: 'Secret key' }), new ConfigService() ); }) describe('when creating a cookie', () => { it('should return a string', () => { const userId = 1; expect( typeof authenticationService.getCookieWithJwtToken(userId) ).toEqual('string') }) }) }); |
Now, we are sure that every test in the authentication.service.spec.ts file gets a brand new instance of the AuthenticationService.
Unfortunately, the above code does not look very elegant. Because the constructor of the AuthenticationService expects some dependencies, we provided them manually so far.
Creating testing modules
Fortunately, NestJS provides us with built-in utilities to deal with the above issue.
1 | npm install @nestjs/testing |
By using Test.createTestingModule().compile() we can create a module with its dependencies resolved.
src/authentication/tests/authentication.service.spec.ts
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | import { AuthenticationService } from '../authentication.service'; import { Test } from '@nestjs/testing'; import { UsersModule } from '../../users/users.module'; import { ConfigModule, ConfigService } from '@nestjs/config'; import { JwtModule } from '@nestjs/jwt'; import { DatabaseModule } from '../../database/database.module'; import * as Joi from '@hapi/joi'; describe('The AuthenticationService', () => { let authenticationService: AuthenticationService; beforeEach(async () => { const module = await Test.createTestingModule({ imports: [ UsersModule, ConfigModule.forRoot({ validationSchema: Joi.object({ POSTGRES_HOST: Joi.string().required(), POSTGRES_PORT: Joi.number().required(), POSTGRES_USER: Joi.string().required(), POSTGRES_PASSWORD: Joi.string().required(), POSTGRES_DB: Joi.string().required(), JWT_SECRET: Joi.string().required(), JWT_EXPIRATION_TIME: Joi.string().required(), PORT: Joi.number(), }) }), DatabaseModule, JwtModule.registerAsync({ imports: [ConfigModule], inject: [ConfigService], useFactory: async (configService: ConfigService) => ({ secret: configService.get('JWT_SECRET'), signOptions: { expiresIn: `${configService.get('JWT_EXPIRATION_TIME')}s`, }, }), }), ], providers: [ AuthenticationService ], }).compile(); authenticationService = await module.get<AuthenticationService>(AuthenticationService); }) describe('when creating a cookie', () => { it('should return a string', () => { const userId = 1; expect( typeof authenticationService.getCookieWithJwtToken(userId) ).toEqual('string') }) }) }); |
There are quite a few issues with the above code still. Let’s deal with them one by one.
Mocking the database connection
The biggest issue above is that we use the DatabaseModule which means connecting to the real database. When doing unit tests, we want to avoid it.
After removing the DatabaseModule from our imports we can see an error:
Error: Nest can’t resolve dependencies of the UserRepository (?). Please make sure that the argument Connection at index [0] is available in the TypeOrmModule context.
To work around it, we need to provide a mocked User repository. To do so, we need to use the getRepositoryToken from '@nestjs/typeorm.
1 | import User from '../../users/user.entity'; |
1 2 3 4 5 6 7 | providers: [ AuthenticationService, { provide: getRepositoryToken(User), useValue: {}, } ], |
Unfortunately, the above error persists. This is because we imported UsersModule that contains TypeOrmModule.forFeature([User]). We should avoid importing our modules when writing unit tests because we don’t want to test integration between classes just yet. We need to add UsersService to our providers instead.
src/authentication/tests/authentication.service.spec.ts
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | import { AuthenticationService } from '../authentication.service'; import { Test } from '@nestjs/testing'; import { ConfigModule } from '@nestjs/config'; import { JwtModule } from '@nestjs/jwt'; import { getRepositoryToken } from '@nestjs/typeorm'; import User from '../../users/user.entity'; import { UsersService } from '../../users/users.service'; describe('The AuthenticationService', () => { let authenticationService: AuthenticationService; beforeEach(async () => { const module = await Test.createTestingModule({ imports: [ ConfigModule.forRoot({ // ... }), JwtModule.registerAsync({ // ... }), ], providers: [ UsersService, AuthenticationService, { provide: getRepositoryToken(User), useValue: {}, } ], }).compile(); authenticationService = await module.get<AuthenticationService>(AuthenticationService); }) describe('when creating a cookie', () => { it('should return a string', () => { const userId = 1; expect( typeof authenticationService.getCookieWithJwtToken(userId) ).toEqual('string') }) }) }); |
The object we put into useValue above is our mocked repository. We add some methods to it later below.
Mocking ConfigService and JwtService
Since we want to avoid using modules, we also can replace ConfigModule and JwtModule with mocks. To be more precise, we need to provide mocked ConfigService and JwtService.
A clean approach to that would be to create separate files for the above mocks.
src/utils/mocks/config.service.ts
1 2 3 4 5 6 7 8 | const mockedConfigService = { get(key: string) { switch (key) { case 'JWT_EXPIRATION_TIME': return '3600' } } } |
src/utils/mocks/jwt.service.ts
1 2 3 | const mockedJwtService = { sign: () => '' } |
When we use the above, our test now looks like that:
src/utils/mocks/config.service.ts
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 | import { AuthenticationService } from '../authentication.service'; import { Test } from '@nestjs/testing'; import { ConfigService } from '@nestjs/config'; import { JwtService } from '@nestjs/jwt'; import { getRepositoryToken } from '@nestjs/typeorm'; import User from '../../users/user.entity'; import { UsersService } from '../../users/users.service'; import mockedJwtService from '../../utils/mocks/jwt.service'; import mockedConfigService from '../../utils/mocks/config.service'; describe('The AuthenticationService', () => { let authenticationService: AuthenticationService; beforeEach(async () => { const module = await Test.createTestingModule({ providers: [ UsersService, AuthenticationService, { provide: ConfigService, useValue: mockedConfigService }, { provide: JwtService, useValue: mockedJwtService }, { provide: getRepositoryToken(User), useValue: {} } ], }) .compile(); authenticationService = await module.get(AuthenticationService); }) describe('when creating a cookie', () => { it('should return a string', () => { const userId = 1; expect( typeof authenticationService.getCookieWithJwtToken(userId) ).toEqual('string') }) }) }); |
Changing the mock per test
We do not always want to mock something the same way in each test. To change our implementation between tests, we can use jest.Mock.
src/users/tests/users.service.spec.ts
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 | import { Test } from '@nestjs/testing'; import { getRepositoryToken } from '@nestjs/typeorm'; import User from '../../users/user.entity'; import { UsersService } from '../../users/users.service'; describe('The UsersService', () => { let usersService: UsersService; let findOne: jest.Mock; beforeEach(async () => { findOne = jest.fn(); const module = await Test.createTestingModule({ providers: [ UsersService, { provide: getRepositoryToken(User), useValue: { findOne } } ], }) .compile(); usersService = await module.get(UsersService); }) describe('when getting a user by email', () => { describe('and the user is matched', () => { let user: User; beforeEach(() => { user = new User(); findOne.mockReturnValue(Promise.resolve(user)); }) it('should return the user', async () => { const fetchedUser = await usersService.getByEmail('test@test.com'); expect(fetchedUser).toEqual(user); }) }) describe('and the user is not matched', () => { beforeEach(() => { findOne.mockReturnValue(undefined); }) it('should throw an error', async () => { await expect(usersService.getByEmail('test@test.com')).rejects.toThrow(); }) }) }) }); |
Summary
In this article, we’ve looked into how to write unit tests in NestJS. To do so, we’ve used the Jest library that comes bundled with NestJS. We’ve also used some of the built-in utilities to mock various services and modules properly. One of the most important ones was mocking the database connection so that we can keep our tests isolated.