Test coverage

[00:00 - 00:11] In this lesson, we are going to explore an important concept in software testing, which is test coverage. Specifically, we'll focus on test coverage in just.

[00:12 - 00:26] By the end of this lesson, you have a clear understanding of what test coverage is and how it can benefit your testing efforts. Test coverage is a metric that indicates how much of your code is executed when you run your tests.

[00:27 - 00:43] It helps you assess the effectiveness and thoroughness of your test suite by measuring the percentage of code that is covered by your tests. The higher the coverage, the more confident you can be that your tests are exercising different parts of your codebase.

[00:44 - 00:52] Just provides different types of coverage metrics to help you assess the quality of your tests. Let's take a look at the four main types of coverage.

[00:53 - 01:13] The first is test management coverage, which measures how many statements you have within your code and how many of them run. The second is branch coverage, which focuses on how many branches or decision points are in your code and how many is tested for saving the total number of parts.

[01:14 - 01:26] It helps you identify your code takes different parts based on conditions or Boolean expressions. This is the most important code coverage metric in my opinion.

[01:27 - 01:43] The third is function coverage, which measures the percentage of functions in your codebase that are executed during testing. It ensures that all your functions, including helper functions, are tested and helps you identify any on use door redundant functions.

[01:44 - 02:05] The last is lines coverage, which is the most granular type of coverage and measures how many lines of code are executed during testing. It helps you identify lines that are not covered by tests.

[02:06 - 02:22] It gives you confidence that your tests are exercising different parts of your application and can catch potential bugs. However, it's important to note that test coverage alone is not a guarantee of bug-free code or comprehensive testing.

[02:23 - 02:38] This is because test coverage focuses on code execution or not, code quality or correctness. And test coverage does not measure the effectiveness of individual tests or the ability to catch specific bugs.

[02:39 - 02:58] To get test coverage in just, we use the dash-cache option. Or in this case, where we're using npm script.

[02:59 - 03:13] I need to prefix the dash-cache option with dash-cache and space. I'll use the author.js file as an example.

[03:14 - 03:19] Here is the percentage of statements. Here is the percentage of branch.

[03:20 - 03:33] Here is the percentage of function and percentage of lines covered by our test. And here are the lines that are not covered by our test, line 31 to 36.

[03:34 - 03:50] And if I go into my author.js file, in line 31 to 36, we can see that this portion of code is not covered by our test. And we need to factor that into our testing effort.

[03:51 - 04:04] Within the user with email, exist function, we create database and this expression can throw an error. It's essential to correctly manage network and error errors to ensure these software's resilience.

[04:05 - 04:13] Specifically, when querying the database errors may occur. We should also include this in our test by checking how well our unit on the test handles errors.

[04:14 - 04:23] In this section, we manage errors when executing the user with email, exist function. It's important to log errors instead of silently ignoring them.

[04:24 - 04:36] Logs can help troubleshoot the application on cover hidden errors and identify errors for software performance improvement. Now we must create a test scenario for the error handling part of this code.

[04:37 - 04:55] To do this, we'll mock the user with email, exist function, similar to what we did in the previous lesson. We'll set it return value to be an error using just mock rejected value, which is similar to mock resolved value.

[04:56 - 05:12] However, since we already have a test case requiring user with email exist to return true from the previous lesson, we'll use just mock resolved value once and mock rejected value once to control what our mock returns the first and second times. It is called.

[05:13 - 05:27] I opted for mock resolved value once and mock rejected value once because there are two tests in this test file. If there were more tests, I could easily chain additional mock resolved value once or mock rejected value once.

[05:28 - 05:45] In the test case, in the arrangement step, we created mock request and mock response objects. The mock response is an object that contains status, which is a stop, and the implementation just returns an object that contains JSON, which is also a stop.

[05:46 - 05:57] And the mock response also contains JSON, which is a stop. In the act step, we execute our sign up function, passing it the mock request and mock response.

[05:58 - 06:13] Finally, in the asset step, we confirm that mock response, the status was invoked and that it must have been called with 500. I'll go ahead and run this test now and issue the run successfully without failing.

[06:14 - 06:33] Finally, let me run just with the coverage option so that we can see the test coverage report. In our OTS.js, we no longer have line 31 to 36 in the uncovered lines.

[06:34 - 06:51] With the last test that we wrote, line 31 to 36 is now covered by our test. One other thing you will notice is because one of our tests chose error, yeah, we can run the just CLI and silently ignore any errors thrown using the silent option.

[06:52 - 07:15] And now we have our test coverage reports without the error being logged to the console. In summary, test coverage in Jest is a valuable metric that helps you assess the effectiveness and thoroughness of your test suite.

[07:16 - 07:33] By aiming for higher coverage and ensuring that different types of coverage are addressed, you can increase your confidence in reliability and resilience of your code. However, it's important to remember that test coverage is just to an aspect of a comprehensive testing strategy, be in the next lesson.