Naming and organizing tests

[00:00 - 00:50] This lesson will explore techniques for organizing tests effectively, including grouping tests, using describe blocks and also utilizing hooks such as before each one writing tests. It's essential to organize them in a logical manner. One way to achieve this is by grouping related tests using the describe function. Describe allows us to create nested structures and assign a descriptive label to each group. By grouping tests, we can easily navigate through our test suite and understand the purpose and context of each test. This improves readability and maintainability, especially as our test suits grow larger. Another advantage of grouping tests with describe is that it provides a more meaningful and informative test report output.

[00:51 - 01:34] When tests are organized using describe the test report, I list the test names with their respective groups. It is completely up to you how you want to style your test and its read ability structure. What I'm showing you here is how you can use describing an effective way. Let's head over to our code editor and make some changes. Before making our change, I'll run the test script and see what our output is. I've made two changes in the user service, the test, the js file . The first is the added describe block that describes the unit of work on the test. Here we use the password correct.

[01:35 - 01:46] To me this looks clearer. It also feels like I can now add more nested tests on this block. This also helps the command line reporter create nicer reports.

[01:47 - 02:18] Talking about the command line, let's run our test script and see what the test report looks like. So improve the output by just test reporter. We need to change the value for this configuration in the just.config.js file which is verbose and we change that to true.

[02:19 - 03:11] You can see the difference now with the reporter including the details for our test suite. Another change I've also made is to nest our test on that the new describe block and remove the name of the unit of work from the test. Besides properly naming and organizing tests, it is also important to avoid logic in our tests like a plague. By that I mean no ifs, no switches or loops or other form of logic. This can easily introduce bugs to our tests and finding bugs in tests can be very bad for more. Another way of organizing tests is to use nested describe blocks to create context along with the its test function. While the its function can be used in all approaches, in this case it fits in more nicely in terms of syntax with the describe driven approach.

[03:12 - 03:44] Here's the change I've made to user service.test.js. We now have nested describe blocks. Still using this use naming format where the unit on the test is a password correct and the scenario is given password and hash. The expectation is that it returns true. In this other test, the unit on this test remains password correct. The scenario is given wrong password and hash and the expectation is it returns false. Let's head over to the terminal and run our test script.

[03:45 - 05:29] Next let's talk about hooks. Hooks are functions that allows us to perform setup and tear down actions before and after tests. The before hook is executed once before any tests in a describe block. It's useful for setting up common resources or performing expensive operations that are shared across multiple tests. The before each hook is executed before each test in a describe block. It's useful for setting up the initial state or reset ting the environment needed for each individual test. As for the after each hook, it is executed after each test in a describe block. It's useful for clean not presources or performing actions that need to be done after each test. Finally, the after all hook is executed once after all the tests in a describe block have finished running. It's suitable for releasing resources, closing connections or performing cleanup tasks that are common across multiple tests. Let's take a look at an example that demonstrates the user of hook. I have added the before all and after all hooks to his password correct describe block. And if I run my test now, before all the tests run, we should have before all hook locked to the console. And after all the tests are done running, we should have after all hook locked to the console. As you can see now Tamina, we have before hook locked here and after all hook locked here.

[05:30 - 07:06] Let's take a look at an example that demonstrates the use of global hooks. We will showcase global hooks using global setup and global tear down configurations. In the just configuration file, we can define global setup and tear down functions. In this example, we log a message when the test suits starts in the global setup function. And another message when the test suits ends in the global tear down function. Here is my just config file. And I added the configuration for global setup and global tear down. Both the global setup and global tear down accept a string, which is the path to the module that contains the setup or tear down functions. And here I have the global setup the JS file and the global tear down the JS file. Each of these files I expected to export an asynchronous function. As for the global setup, it runs once before all the tests. Here you want to perform setup operations like maybe setting up a database schema and similar things. As for the global tear down, you turn to once after all the tests complete. And if I open the terminal and run our tests, you should see a console.log message of global tear down in the terminal. By organizing our tests using describe blocks and utilizing hooks like before all, before each, after each and after all, we can keep our test suits well structured and maintainable.

[07:07 - 07:22] Additionally, global hooks in just configuration files allows us to perform setup and tear down actions at the test suite level. This promotes better organization and efficiency in our testing process. See you in the next lesson.