Code Coverage

[00:00:00]
>> I would like to take an opportunity to talk about a particular technique that I use when I'm testing and I'm working with a large team. And so, it's important that when we talk about building, production, applications, whether it's angular,nest, node, whatever it is, that you have, some metrics in place to determine is this of sufficient quality.

[00:00:28]
And I believe that if you are talking about production and your application, behaving as intended as expected, that there's this implied level of, I think quality that exists with that. And so when you're working with a team, you have to ensure that not only does it work, but it works well.

[00:00:48]
And as you continue to work on your application that you're not introducing regressions and so this is why I believe testing is such an important part of building production applications and so one of the things that I typically do when I'm on a new project or I'm working with a team, is I asked about their code coverage.

[00:01:14]
And usually, I would say on most functional teams that there's a certain kind of a threshold that they're looking for in terms of code coverage. So for me, I tend to look for like an 80% code coverage on my unit test. So that's just a good kind of a nice metric that allows you to at least cover kind of the major portions.

[00:01:38]
And so when you're writing unit tests, you definitely want to go for quality over quantity. So I think for instance I've seen some organizations just like double down on like 100% code coverage. Well, that doesn't make a lot of sense because what happens is you have things that are just not really testable, or there's it's not really doing anything that affects the main application.

[00:02:01]
So you get a lot of these noisy tests that it's just like assert true equals true. But the one thing I do want to show you, Is how to set up code coverage in your angular application in a way that is meaningful. So what I'm gonna do is I'm going to hop into the command line and I'm going to just run our test.

[00:02:26]
So I'm on the unit testing branch and NX RUNS Dashboard command test. And so this is going to run and I expect that it's probably going to do okay. I think we'll have, There we go so everything passed, there's one test that I'm skipping, not a problem, the main thing is we have five test suites and in total, we have nine test.

[00:02:52]
But what I wanna do is I want to show how to do this with code coverage. So you can use this --code desk coverage, and there's a shortcut key for this if you want to look it up in the documentation. And because we're running Jess, this is cached output, and so it's almost immediately.

[00:03:12]
This is one of the nice things about Jests, and if you go into your project, and let's just collapse everything. You notice that you have apps, and then underneath of this, you have coverage. And so it's apps dashboard, and then what you have Is essentially this generated application that will show you coverage.

[00:03:39]
And what I'm going to do is I'm not going to bother opening this, Instead, what I want to do is I want to jump into the Jest.config for the particular application that I'm in. So you have to do this per application, but in the case of dashboard, I'm gonna go to jest.config, and I'm going to add a line.

[00:04:00]
And so what this line is, there we go, so they got for command C is I'm adding a coverage reporters and I'm saying, I want the reporter. Instead of being this default HTML, I want it to be text, so let's hop back into the command line. And let's run this one more time.And so this is a really simple technique.

[00:04:26]
But it gives you a really good idea when you're running your application where you are lacking in terms of code coverage. And so what you can do here Is currently on this branch. I have 92% code coverage on all of my statements now on my functions, it's a little less.

[00:04:50]
And so even go here and even say, I'm a little weak on App component.ts. The fact that I'm skipping the home component. That hurts, but now this is a very quick way for you to go and look and say where's this week. And I have worked on a lot of projects where this is a requirement for APR to get in that if you submit APR that in the CICD pipeline, they will evaluate your code coverage.

[00:05:22]
And if you submit code in a false below that threshold, then it'll essentially raise that flag and then you're forced to go and write tests and adequately cover that. So just to summarize real quick before we move on is. All I've done here is I'm running my end to end test with this code coverage flag.

[00:05:45]
And to surface this in a way that it makes sense to me visually in the code, you go to the project or the app that you're on, and then you can just add this coverage reporters entry. And then for me, I just change it to text so that it is outputted into the console.