 This lesson is going to be all about capturing code coverage with Xcode. And if you're not sure what code coverage is, it is simply the percentage of code that's covered by your automated tests or your unit tests. And Xcode has a feature that you can turn on where Xcode will automatically gather the code coverage percentage for you and display it for you at the end of your unit test session. So we're going to dive into that, learn how to turn this feature on and how to utilize it and take advantage of it when we write our unit tests and our production code. So let's open up Xcode and get started. Code coverage is a way of determining what portions of your code are covered by unit tests, essentially. And it's important as you start to work on larger projects with a growing code base to make sure that you're applying principles of test-driven development. Now, this is a controversial issue. It's not necessarily something that mobile developers apply to their programming patterns, but it's a really powerful concept once you understand and grasp the benefits of it. And it's a great discipline to utilize in your day-to-day work. I have an example project here, and it's just a framework with one class in here called Programmer. And it's really simple. And I'll walk you through it before we actually go through the tests and the code coverage. But basically, it's class. It has two properties. It has a name, which is a string and a programming language. So there's an enum in here with a few different languages, Swift, Kotlin, JavaScript, all the way down through Objective C. And then there's two functions. There is an initializer that takes in the name, the language, assigns the properties. And then there's another function here for, is a mobile developer, which returns a pool. And it's an arbitrary example. But if you, in my example code in Swift, Kotlin, Objective C, or Java, see? I already made a bug. Then we return true. Otherwise, return false. Now, if we wanted to try to understand how we can utilize unit tests to cover this code adequately, to make sure that we have proper code coverage in here, how would we do that? And in this lesson, we're going to go through how to set up our unit tests to capture code coverage and some of the patterns and techniques to making sure that we are correctly and accurately getting code coverage as we write our unit tests. So let's go into our unit tests in here. Now, I have a unit testing target as a part of this project, and that's going to be required to go through these steps. But when I go to my assistant editor here, and let's bring up our programmer class on one side. So I can go ahead and run my tests and just verify that everything builds. And what I'll do while that's going here is just delete some of this stuff. And we're going to write a unit test. What we can do here is create a new function. And we're just going to call it test initializer. And we'll just do a um let programmer equals programmer. And we'll give them Swift. And we'll just copy this here. Let name, expected name, paste that in here. Let expected language equals dot Swift. And drop that in here. And what we can do here is write our assertions. So we can just do, you know, XET assert that the programmer dot name equals expected name. And XET assert programmer dot language is the expected language. And we can go ahead and run our unit test here and just observe. Let's let this run. And here's that test over here. And so we can see our test passed. And that's great and all, but there's a nifty feature in your unit test schemes that can really enhance the power of your tests and maybe even motivate you to really want to write better tested code. Now if you go to your schemes under manage schemes, I only have my framework target listed here. Now if I go to plus and I look in the dropdown, there's actually the demo test scheme. So what I can do is it okay to add it and hit close. So if you go back into your dropdown here, you'll see that you have the framework scheme and the unit test target scheme in the list. With the unit test target scheme, go ahead and select it and do edit scheme. And go under the test section here. And then go under the options here. It's the third one. And you'll see that there's a little check box for code coverage. And if you check that code coverage percentages will be gathered by X code for all the targets, or you can specify a particular target, maybe a particular framework or an app by default, all targets is good enough. And so all you do is check that off and hit close. And let's run our unit test one more time, but let's open the left side of the navigator here and run our tests. And you can see here that now I have this little coverage section under the test status. And as the test runs and it completes, now there's a percentage being basically captured. And if you look back at the unit test, you'll see that there's this green block here with a number next to it. And then right below it in the other function, there is a red block with a zero next to it here. So what is this telling us? It's telling us that 22% of our code is basically covered by the unit tests, that there is code executing this, running it, this code is covered by something by our unit tests. And right now that's our initializer because that's the only test we've written. Now, if we wanted to increase our code coverage, we would write a unit tests for the function is mobile developer. And what we can do here is go ahead and see that in action. So let's go back to our tests here. And funk test is mobile developer. And I'm just going to copy this code from here and paste it right into the unit test. And let's go ahead and close the left side. And let's do this. So we want to do let is mobile programmer equals programmer dot is mobile developer xct assert, because we passed in Swift, we can do an assert true on is mobile programmer. Because that's what the logic in this function says. If you are Swift is one of your languages return true. Let's go ahead and run the tests. And so right away here, we can see that this block has changed. Now there's a little green section here under the return true. There's still some red here because we haven't exercised this code block yet. And there's a number one here for what's basically how many pieces of code are covering this or how many unit tests are exercising this function. If we go back and look at our coverage percentage again, we can see that it just jumped up from 22% to 66% coverage just by adding that one test there. So at this point, you might be thinking, all right, you know, I've got 66% coverage. I want to increase it. So what do I need to do? Well, you can look at what you have in red and determine how do I construct a test that exercises this particular scenario. And if I can't reach it because maybe I wrote the code in a particular way that makes it hard to test, well, then maybe I can rewrite particular code to make it easier to test. And that inadvertently helps improve the quality of your code. Overall, the more you start to do that if you run into the scenarios. So again, what we can do here is create another test. And I'm going to modify the name of this one. Returns true. I'm going to copy this exact test. And I'm going to paste here. And instead of returns true returns false. I'm going to say that this is a JavaScript language. So we might assume this is a web developer instead of a mobile developer. And from assert true, assert false. Now let's go ahead and run all of our tests. And okay. So it looks like everything finished here. And so we're looking here and say, okay, we got some green there. We got some green in this block here for the returns false. But what is this here? Why is it zero here? And there's a little bit of red. Let's go take a look at the percentage and see what changed. So now we're at 94.4%. But not fully 100%. And the reason for that is because we still have a path here that wasn't necessarily covered. Obviously, you know, we structured in such a way where it's going to return true or false no matter what. But if we, for the sake of wanting to increase this coverage to 100%, we can slightly modify this function to do that. And what we can do here is a simple trick of doing something like this. Var is mobile developer. And we'll default it to false. Like that. We'll get rid of the alt block here. We are going to say, if he is any of these four languages, we're going to set that to true. And we'll return his mobile developer no matter what. Now, functionally speaking, the logic of this code didn't change. I just slightly modified the code path to maybe be a little bit simpler by defaulting to false. And we always return false unless there is a particular case of returning true without needing an alt block to check it. Kind of simplifies things in some ways. As a byproduct of doing that, I was able to improve the testability of this function, allowing me to get to 100% coverage by just making that change. And so as you develop, and if you implement these principles going forward, you'll not only improve the quality of your code, but you'll improve the testability of your code, which is arguably just as important to writing good quality code. Now, if we add a new function, let's just say, func is Android developer. And if R is Android developer, false return is Android developer. Programming language equals dot Kotlin. Is Android dev equals true? Is that the true? So now, because we don't have a unit test for this and make sure that returns a bull, let's run our tests one more time. And because I added that new piece of code, I don't have any unit tests that cover this method. So naturally, as a byproduct of that, my code coverage percentage is going to drop again. Now, it's down to 64%. So as you increase the code, if you kind of run this and keep an eye on it throughout development, you can see how much of your code is covered under unit tests, and where you can make improvements. And more importantly, it provides metrics. Sometimes your boss is going to be like, hey, like our code sucks, we need unit tests, we want, you know, a certain amount of coverage, you guys need to do it. So this is the metric that you can report back and be like, hey, you know, we have this much percentage of our code covered. This is how we're doing it. These are our goals to get there. And it kind of provides some transparency into maybe some managers who don't know the technical innards of what you guys do as programmers. And it kind of provides a way to build trust, improve quality, improve the reliability. And overall, it's a really good practice to implement. So that wraps it up for this one. But again, this is a powerful concept that you can easily apply to any of your projects and produce much better results. And that wraps up this lesson. So hopefully you can apply code coverage in your apps going forward and really improve the reliability and stability of your code and motivate yourself to write more unit tests and keep that percentage nice and high. So if you like this video, go ahead and smash that like button, consider subscribing to Code Pro to stay up to date for all the latest tutorials and lessons. Make sure you follow me on social media. You can find Code Pro on Facebook, on Twitter, on Patreon, Udemy, and Skillshare. And let me know in the comments section down below what percentage of code coverage do you have turned on? Is it zero, 100% somewhere in the middle, or do you not even have the feature enabled? Thank you so much for stopping by and I'll catch you in the next one.