Let's zoom in on this small or unit test. What are the investments that these things require, and what are the rewards that they deliver? While the investments really have to do with creating these tests and maintain them across your codebase. A lot of developers that they don't like to do this find that the stubbing and the mocking that these things require is more overhead than they feel is warranted. If you call the idea with these unit tests is that they're very isolated and modular. So, if we have a single piece of software, or a single function, and it talks to another function, we simulate that interaction, and that does take work, that's part of creating these tests. If you want to have a little more texture on this debate I included a pair of posts one from an agile is named Kent Beck who is pro unit test, and pro test-driven development this approach of leading with tests, and one that is in opposition of it because from a guy named who goes by his initials DAHH who says, "I just don't find that the overhead that stubbing and mocking all my functions requires delivers the value that I would want from doing this." So, if you're interested in more detail on this, take a look at that. The other thing your team may find is that as they create these unit tests, they find that they need to change their code to have if they've really long functions, the functions they want to move to be more unit test friendly are shorter, and maybe manage their external dependencies in a different way. That kind of pairs with the reward of having code that most developers will find more readable and just generally more maintainable. All that said, you don't have to do this stuff from scratch, there are tools that most folks will use in all the major programming languages. For example, in Java, JUnit, and JavaScript, Jasmine, in Python there's a tool called Mock, there are several options for each of those and what these tools do is create an infrastructure, and some help with this mocking and stubbing and generally the housekeeping or maintaining these tests. So, there is that to kind of help. Then there's this question of test coverage. There are a lot of tools that will allow you to take a codebase and say what percentage of this codebase has unit test coverage. That's a really useful thing to know on at least a first order basis. So it doesn't have 10 or 80 percent, and a lot of teams will use this to understand the amount of technical depth that they have if their goal is to have good unit test coverage. How much unit test coverage should you have? There is a great Quora post a question what somebody asked, what's a reasonable percentage of test coverage? There is somebody who wrote a little parable, or found it somewhere and posted it there, that's in the course resources, it is informative and amusing. The basic answer is it's a little bit different for each individual developer in each situation, but probably the best way to get to a good answer on that is to look at how these unit tests are delivering for your team and your pipeline on each individual iterations. So, if you work in one week, two week, three week, four week whatever it is cycles, at the end of each one when you have a retrospective, and you ask, what went well? What do we want to change? You look at how the unit test investments perform for you, and what was the root cause of any kind of bugs that made their way out of the pipeline into production. So, with diligence and with focus, you will get to the right answer on this job of unit tests. Let's take a look at these things in a little more detail.