00:00 Right now, Vitas supports two code coverage providers, V8 and Istanbul. Those are third-party packages responsible for calculating that percentage of code coverage. We're going to use the V8 provider in this exercise, so let's install it. Open your terminal and run npm install at vitas-codecoverage-v8.

00:17 Let's save it as a dev dependency. To enable code coverage in your tests, head to Vitas configuration, and in the test object over here, add another property called coverage. This will also be an object that we'll have enabled equals true. This enables code coverage for your test run.

00:33 Next, specify the coverage provider that you want to use, so in our case, provider will be V8. And then choose how Vitas should report the coverage back to you by providing the reporter property, which can be an array, and you can combine multiple coverage reporters. For example, the text reporter will print the code coverage report directly in your terminal output after your test run.

00:53 I will use the text reporter as well as the HTML reporter that will create a tiny interactive application for me to explore my code coverage. And finally, there's a little tip you can use to make code coverage runs faster. You can provide an explicit include property here, and unlike the same property for your

01:09 tests, you can use the include for code coverage to narrow down the file patterns that Vitas should use to understand where to collect the code coverage from. So we can say, we're collecting code coverage from all TypeScript files in the SRC directory. And because we're helping Vitas here and narrowing down the files it should read, this will make the test run faster.

01:28 Now that we have code coverage configured, we can get the report by running our tests. Let's do just that. In the terminal, let's run NPM tests, and you can see this coverage table at the end of your test run printed by the text reporter that we provided previously. This is really great to get a fast feedback on how your code coverage changes, but today

01:47 I wanted to show you how you can explore that coverage report in a more interactive way. For that, we're going to need the UI mode in Vitas. And since that's a standalone feature, let's first install it. So in the same terminal, let's run NPM install at Vitas slash UI, and this will install the

02:04 UI mode and we'll be able to use that for our test in Vitas, not just code coverage. Now to run Vitas in UI mode, let's run NPM test, the same command we used before, and now provided the dash dash UI flag. This will open a browser tab where you'll be able to explore your test run in a more visual way.

02:21 Today we're interested in this button over here, this little folder that says coverage. Once you click on it, you will see the same code coverage report, but presented in this nice table. You can see this Fn.ts, our tested code, and the different criteria of code coverage report like statements, branches, functions, and so forth.

02:39 So right now you can see that we're at 66% of code coverage. If you click on any particular module here, Vitas will show you even more information. So in this case, it will print the source code of our tested function and show us which branches and which statements were hit in the test, in other words, were executed during the test run.

02:56 And also in this red indication here, it will show us the code that was not run at all. And we can use this information to help us guide our testing strategy. Like in this case, we're clearly missing one test case for Fn function. So let's add it in tests.

03:11 I will keep Vitas running and head straight to this Fn.ts.ts file, our test file for this function, and add a new test case that says returns, okay, if given a number less or equal to 10. And I will provide a few new test cases here, like calling Fn with one to be okay, and maybe

03:31 calling it with 10 as well. And once I do that, Vitas will rerun the test in watch mode and also update the code coverage automatically. So in the UI mode, I can see that now we're hitting 100% code coverage on all of the criteria. And you can also see this in this nice implementation view too.

03:48 I think that using the UI mode is a great way to explore the code coverage and find weak spots in your test suite, which brings me to the next point. When should you use code coverage? Despite being a precise metric, having 100% code coverage doesn't mean having great tests.

04:04 Unfortunately, such metrics can often be gamed or even deceived, and that happens in practice all the time. Developers set those metrics as the end goal of their entire testing effort. And that cannot be any further from the truth, because the whole point of automated testing is to describe your intention towards the tested system.

04:22 And you already know that code coverage by design is based on the implementation. That implementation doesn't necessarily map one-to-one to your intention. And often chasing 100% code coverage can be even detrimental to your test suite. That is not to say that code coverage is entirely useless, not at all.

04:38 You can use it to a great effect when exploring existing code bases, especially those having poor test coverage, because it can help you highlight problematic areas and areas that can use your attention. You can also use code coverage as a sanity check to make sure you haven't missed anything once you've written your tests.