[MUSIC] In this lecture, we will discuss Code Coverage. How much have we been testing or not testing in our application? To get started with test coverage, we need to visit our Gemfile and add this simple coverage Gem And run bundle. You also need to edit our spec_helper. And add a configuration that, if we supply the environment variable coverage, then it'll bring in simple coverage, Gem. And we'll define specific reports like a report centered around foos, a report centered around bars. And to ignore reporting on coverage on things in the spec folder, or anything in the config folder. So we run our test by adding coverage equal true prior to the execution. And it tells us that it has written some files into the coverage directory. If we navigate to our application, go into the coverage, index HTML, we see a front page of a report giving us an indication of the percentage of the class that's been tested, the number of lines in it, relevant lines and things like that. And then a break down of here's your testing around foos, here's your testing around bars and here are the classes that aren't in any groups. And you know, we've seem to have done a pretty nice job at testing what's there. If we were to go into an individual class, it's telling us what we have and have not tested. And here's a piece of useful information. We have not tested a create failure. And we have not tested an update failure. And just in staring at this, I see a problem. Notice how we're reporting the error in these cases? It's just a straight what are our errors. Well if you remember our application controller, it actually did some formatting. So this report is pointing out initially that even though we have almost 92% of our classes coverage, we failed to test an error case. Interesting stuff. All right, I'll leave it to you to dig in and see what else we can find. But one of the last things we probably want to do is add that directory to our gitignore because we don't need to clutter our repository up with stuff like that. And then, actually, that is a good candidate report for the build server to kick out. Let's see if we can find the time to do that. Okay, so in summary, hopefully we all can agree that testing our application is a very important thing. And that a Code Coverage report can do two things, it can provide confidence that we have tested our application, or it can identify gaps in our testing. Which we actually saw as a part of our foo testing. What's next, security. Actually that's not next. There's an assignment before we get to security, but when we get there we'll be talking about authentication, authorization from the back end server to the front end web displays. It's going to rock.