API with NestJS #102. Writing unit tests with Prisma


This entry is part 102 of 125 in the API with NestJS

Covering our NestJS application with unit tests can help us create a reliable product. In this article, we introduce the idea behind unit tests and implement them in an application working with Prisma.

In this article, we continue the code developed in API with NestJS #33. Managing PostgreSQL relationships with Prisma

Introducing unit tests

A unit test ensures that an individual piece of our code works properly. With them, we can make sure that various parts of our system function correctly in isolation.

When we run , Jest looks for files with a specific naming convention. By default, it includes files ending with . Another popular approach is to create files ending with . We can look it up in our file.


Let’s create a basic test for our class.


PASS src/authentication/tests/authentication.service.spec.ts
The AuthenticationService
when creating a cookie
✓ should return a string (12ms)

In the example above, we use the constructor of the manually. While that’s a possible solution, we can depend on NestJS test utilities to do it for us. To do that, we need the method from the library.


Avoiding using a real database

When we take a look at our , we can see that whenever we initialize it in our tests, we establish a connection with the database using the method.

An essential thing about unit tests is that they should be independent. To depend on them, we need to ensure they are not affected by any possible issues with the database. The method in our does not require a database. However, a lot of other methods use the database. A good example is the method.


To test the above logic in a unit test, we need to avoid making a request to the database.

When we look at our implementation of the , we can see that it does not connect to the database directly. However, it uses the under the hood. We can provide a mocked instance of the that does not use our database.


Above, we provide a mocked version of the with the method that always returns the data of a particular user. By doing that, we can know that our test won’t try to query users from the actual database.

Modifying our mock per test

In the above test, we assume that the method returns a valid user. Unfortunately, that’s not always the case:

  • when we provide an email of a user that exists in our database, it returns the user,
  • if the user with that particular email does not exist, it throws the .

Let’s modify our mock before each test to cover both of the above cases.


The AuthenticationService
when the getAuthenticatedUser method is called
and a valid email and password are provided
✓ should return the new user (106 ms)
and an invalid email is provided
✓ should throw the BadRequestException (10 ms)

The essential thing to notice above is that we are not testing the itself. Focusing on a single class or a function is the essence of writing unit tests. We don’t check how classes work together but make sure they work as expected in isolation.

Mocking Prisma

So far, we’ve been able to avoid using our real database by mocking the . However, we should also test the class. Let’s take a quick look at the method.


There are two major cases above:

  • if the method returns the user, should return it too,
  • if the method does not return the user, should throw an error.

In order to test all of that, we need to mock the .



In this article, we’ve learned about writing unit tests with NestJS. As an example, we’ve used services that use Prisma to connect to our database. While we don’t always have to mock Prisma to avoid connecting to the actual database, we definitely need to know how to do that. There is still more to learn when it comes to testing with Prisma and NestJS, so stay tuned!

Series Navigation<< API with NestJS #101. Managing sensitive data using the AWS Secrets ManagerAPI with NestJS #103. Integration tests with Prisma >>
Notify of
Inline Feedbacks
View all comments