# Some theory & First test

Now, let's begin to write the unit tests for the <mark style="color:blue;">`UsersService`</mark>. Inside the file <mark style="color:purple;">users.service.spec</mark>, we may then continue our discussion.

Basically, these test files are organized in two main kinds of blocks:

* <mark style="color:blue;">`describe()`</mark> - describes elements or scenarios and groups closely-related tests together
* <mark style="color:blue;">`it()`</mark> - short for **individual test**, the test itself

{% hint style="info" %}
The <mark style="color:blue;">`it()`</mark> name also makes the test name more readable, for example: *<mark style="color:yellow;">**it**</mark> <mark style="color:yellow;"></mark><mark style="color:yellow;">should do something</mark>*.
{% endhint %}

Therefore, as we are testing the methods of the <mark style="color:blue;">`UsersService`</mark>, its natural that we have the following organization:

* First, everything is put inside a <mark style="color:blue;">`describe()`</mark> block for the <mark style="color:blue;">`UsersService`</mark> itself
* Then, inside it, we should have a <mark style="color:blue;">`describe()`</mark> for each one of its methods
* After that, inside each one, we can have a <mark style="color:blue;">`describe()`</mark> for each possible scenario
* Finally, inside them, write the <mark style="color:blue;">`it()`</mark> block or the test itself

Very well, but notice the <mark style="color:blue;">`beforeEach()`</mark> method. Inside it, logic is executed **before each test**. Alongside it, there are three other methods that execute at distinct moments:

* <mark style="color:blue;">`beforeAll()`</mark> - before all the tests
* <mark style="color:blue;">`beforeEach()`</mark> - before each test
* <mark style="color:blue;">`afterEach()`</mark> - after each test
* <mark style="color:blue;">`afterAll()`</mark> - after all the tests

So, what happens here is that, before each test, a <mark style="color:blue;">`module`</mark> of type <mark style="color:blue;">`TestingModule`</mark> will be initialized with just the <mark style="color:blue;">`UsersService`</mark>. After that, a variable for the <mark style="color:blue;">`service`</mark> obtains its reference from within the <mark style="color:blue;">`module`</mark>. It's done like this because unit tests should be performed in **isolation**, so we should test <mark style="color:red;">only</mark> the <mark style="color:blue;">`UsersService`</mark>. Any external dependencies should be **mocked**, that is, have a simplified representation. We will <mark style="color:red;">not</mark> test the <mark style="color:blue;">`Repository`</mark> from TypeORM, we should **assume** that it works properly because it's <mark style="color:red;">not</mark> our responsibility to test it. Our focus should be <mark style="color:red;">only</mark> to test **our own code**.

Due to this, before each test, we have a fresh <mark style="color:blue;">`service`</mark>. The first test, which comes by default, is the *<mark style="color:yellow;">it should be defined</mark>* test. It simply **expects** the <mark style="color:blue;">`service`</mark> to be defined. The <mark style="color:blue;">`expect()`</mark> function receives an argument and checks whether it meets certain conditions. It can be chained with many useful functions to perform different assertions, such as <mark style="color:blue;">`toBeDefined()`</mark> in this case.

It will obviously <mark style="color:green;">pass</mark>, right? Actually, it will <mark style="color:red;">fail</mark>. This is because the <mark style="color:blue;">`UsersService`</mark> relies on the <mark style="color:blue;">`Repository`</mark>, which is not included in the <mark style="color:blue;">`module`</mark>. But we should <mark style="color:red;">not</mark> use the actual <mark style="color:blue;">`Repository`</mark>, <mark style="color:red;">nor</mark> connect to a database. As was said, this breaks that isolation principle mentioned earlier. So, at least for now, let's have the <mark style="color:blue;">`repository`</mark> as an empty object, in the <mark style="color:blue;">`providers`</mark> of the <mark style="color:blue;">`module`</mark>. To represent a <mark style="color:blue;">`Repository`</mark> here, we can use the <mark style="color:blue;">`getRepositoryToken()`</mark> function, passing the entity as argument.

```typescript
provide: getRepositoryToken(User),
useValue: {},
```

By executing the test again, now it <mark style="color:green;">passes</mark>! We're about to begin our first test, but first, let's just see some more fundamental theory.

Tests ideally should follow the **AAA pattern**, which means:

* **Arrange**: Set up the data necessary to perform both the **test** and the **assertions**
* **Act**: Peform the test itself, using an actual element of the system
* **Assert**: Verify if the output of the test is what it should be

Let's then write our first test, for the <mark style="color:blue;">`findOne()`</mark> method. It receives an <mark style="color:blue;">`id`</mark> and returns a <mark style="color:blue;">`user`</mark>, so we'll perform these steps for now, following the AAA pattern:

* Create a **fake** <mark style="color:blue;">`id`</mark> and an <mark style="color:blue;">`expectedUser`</mark>
* Call the method in the <mark style="color:blue;">`service`</mark>
* Check if the obtained <mark style="color:blue;">`user`</mark> matches the <mark style="color:blue;">`expectedUser`</mark>

```typescript
describe('findOne', () => {
  describe('when user exists', () => {
    it('should return the user', async () => {
      const id = 1;
      const expectedUser = {};

      const user = await service.findOne(id);

      expect(user).toBe(expectedUser);
    });
  });
});
```

This will, however, not work because the <mark style="color:blue;">`repository`</mark> is an empty object. The <mark style="color:blue;">`service`</mark> will attempt to invoke a <mark style="color:red;">non-existing</mark> method in the <mark style="color:blue;">`repository`</mark>, causing the test to <mark style="color:red;">fail</mark>. How could we solve this? Well, the <mark style="color:blue;">`repository`</mark> should have its methods as **mocked functions**. They represent functions **without any actual logic**, but this implementation can be mocked for each specific test. Let's then learn how to have a **mocked repository**.