[Track 4/7] The tests 🤓

[taki-tiler-server[bot]]

Step 1/5 - First test setup

Estimated time: 1 hour

Now you're going to work on another super-important concept on the process of building your own server. Have you ever stopped to think about how you would test if your code works? 🤔 If you thought about performing the query/mutation on one of those applications (browser, graphiql, graphql playground) and checking if it works as expected, that's one way of doing it. But we have a more solid proposal: writing more code for tests! The principle is simple: you give an input and check if the response is the expected. Why is it better? Well, some advantages:

1. The time gain: you write your test once, and then you can run it whenever you want.
2. While you develop other features, you can keep running the tests for all the previous implemented queries/mutation to make sure they are still working.
3. Test codes can serve as a kind of documentation as well. People who read them are able to know all the particular scenarios of a query/mutation.

If you search on the Internet, you'll find out there are many ways to test a code. Depending on the project, people decide to use one, or several of them. Here, we're going to write Integration tests. For each query/mutation of your server, you're going to setup the database for them, provide some input scenarios, and then check if the response is given as expected. Take some minutes to read about them on the Internet.

Set up tests on your server is not an easy tasks. There are a couple of things to learn and prepare first. We're going to create a step-by-step to help.

As you can imagine, giving the previous steps, there are more cool libraries to help us on this process. We're going to present them one at a time.

The first one is the main library to write the tests codes: mocha. Take a look at their docs. It's important to know that mocha provides some methods that can be executed like a timeline. This is very useful to handle tasks in specific orders.

Your task is very simple in this first step:

• Install the library. You can use the devDependencies to install it. Would you be able to say why? 🤔
• Create a test folder on the root of your project with an index.ts inside it.
• Create a script on your package.json to run your tests with npm run test
• Write a simple test with describe/it that just print something. If it's running properly, go to next step.

[hmartinsc]

next

[taki-tiler-server[bot]]

Step 2/5 - Other library: supertest

Estimated time: 1 hour

Another of those cool libraries is supertest. This library is makes our work of performing requests to our server easier. Take a look at their docs.

Now, let's increment our step-by-step for the test execution:

1. Start the server
2. Run a single test

In order to acomplish this new first step, your task is to:

1. Install the library
2. Change your code to start the server before(() => {}) (🤣) beginning the test
3. Use the request function of supertest to communicate with the server you just started. You can use the localhost:port for this.
4. Try to perform your previously implemented Hello query, from the graphql-yoga setup. For now, just check if it's working with console.log

NOTE: you can open a pull request after this step, so we can check if your setup is going ok for now.

[hmartinsc]

next

[taki-tiler-server[bot]]

Step 3/5 - The last library (for now)

Estimated time: 30 minutes

The last library fot tests is chai. Chai is a very complete library that handles assertion, i.e., checking if the result has the values that were expected to have. As usual, take a look at theis docs, install it on your project and try to use the expect function to compare the return of your Hello query with the expected value.

Try to use these functions as if you were writing a sentence, to improve readability. For example:

expect(queryResponseField).to.be.eq('Hello, Taqtiler!');

[hmartinsc]

next

[taki-tiler-server[bot]]

Step 4/5 - Database and environments

Estimated time: 1 hour

Now we're going to include the database on our tests. After all, we should test if our queries will be returning what is on the database correctly, and if our mutations are changing the database accordingly.

Do you remember we talked about setting up 2 containers because we were going to use 2 databases. Yeah, the north remembers 🐺! As a preparation for this step, you're going to prepare 2 environments: the one you're already using to develop with npm start and one additional to run the tests. Do some reasearch about the importance of having separate environments on our development workflow. We will talk about it sometime on our meetings too.

One way of handling separate environments is to use environment variables. They are variables that can be set for each environment, so when we start our server on that environment, we use the specific values for it. We could have as environment variables, for example, our database host, user, url, etc...

Your task now is to set some environment variables to connect with the right database for each environment: localhost and test. Create a .env and a .env.test file to store the values of these variables. This package can help you on reading the right file depending on the environment you're running.

Now, our step-by-step for the tests is incremented again:

1. Connect to database (the test one)
2. Start the server
3. Run a single test

[hmartinsc]

next

[taki-tiler-server[bot]]

Step 5/5 - The Login Mutation test

Estimated time: 3 hours

Now it's time to (finally) write the tests for your recently implemented LoginMutation. But first, some theory: unlike our simple Hello query, this mutation is integrated with database. How should be these tests? Well, some general good practices every test you're going to perform. Replace your current 3. run a single test step with:

• Setup the database: to check if some feature is working, most of the time we need to have a certain state on the database before running the test. For example, we should have at least one valid user on db to make a successful login
• Create an input: you should create one example of input to run your query/mutation. On your login example, it should be a user/password, with an optional rememberMe.
• Run the test: well.... Run the test 🏃.
• Check the response: Given the input and the state of database previously set up, you should check if the response is returned as expected. On a successfull login test of yours, a token should be generated and the user info should be returned
• Check the database after the test: in some cases, we change the database after the request. We should check not only if the response is as expected, but also the new values on db.
• Clear the database: we want our tests to be independent, so we can make sure every piece of our lego works and can be properly united on a good system. So, it's important to reset the state of the database after every test, so the next one can be clear to run. You can read more about the importance of independant tests on the internet. We should talk about this too.

Write some tests to your LoginMutation. Try to follow those good practices above, and try to predict on your tests as many scenarios as you can, so the tests can be more complete. Some examples:

• Successful login
• Wrong e-mail or password
• User not found

If you finished the challenge, you can also check if the token duration is behaving as expected according to rememberMe input

NOTE: don't forget that you should connect to the database before (not that joke again) beginning the tests. And it should be the right one. NOTE 2: don't forget to open a PR with your tests.

[hmartinsc]

next

[taki-tiler-server[bot]]

Click here for your next track