Solution Code Coverage for Java Programming
Solution Code Coverage for Java Programming
Learn to Code using Java programming language. Enrol now in our Java Programmer Nanodegree program - http://bit.ly/2Yi677f.
Content
0 -> Despite all the advice and the conventions surrounding unit tests,
4.125 -> it can still be hard to know if you wrote them correctly.
7.514 -> The perfect unit test suite would find all bugs in
10.77 -> your code but what finds bugs in your unit tests?
14.88 -> If we could write perfect unit tests,
17.46 -> we probably would just write perfect code in
19.5 -> the first place and not need unit tests at all.
22.185 -> But of course, that is not the case.
25.065 -> How do we evaluate our unit tests for fitness?
28.845 -> One way to test the tests,
31.32 -> so to speak, is to see if they actually run all your code.
35.67 -> This measurement is referred to as code coverage,
39.404 -> or sometimes test coverage.
41.92 -> Coverage is a measurement of what percentage of
44.57 -> your source code is executed by unit tests.
47.675 -> Usually we'll look at lines,
50.21 -> but it's also useful to look at coverage of methods and classes as well.
54.88 -> Let's look at an example of evaluating a unit test for code coverage.
60.184 -> Here is a simple service implementing the classic toy problem, FizzBuzz.
65.515 -> This method takes a single integer and returns the word Fizz,
71.149 -> if the integer is a multiple of three,
73.765 -> Buzz if the integer is a multiple of five,
76.91 -> and FizzBuzz if it's a multiple of both three and five.
81.38 -> This is a silly problem,
83.135 -> but it's good for demonstrating code coverage.
85.645 -> Here's my FizzBuzz service test class and you can see that I've
90.17 -> broken out my test logic into three different methods that each test,
94.4 -> one of the three scenarios I want to cover.
97.345 -> Multiples of three, return Fizz.
101.655 -> Multiples of five, return Buzz,
105.035 -> and multiples of three and five return FizzBuzz.
109.465 -> Let's run the first unit test for code coverage.
113.33 -> In IntelliJ, if I right-click on the method,
116.12 -> I can select the option run with coverage.
120.37 -> A new window appears showing me the class,
124.3 -> method and line percentage coverage organized by package.
129.409 -> If I double-click on this package,
131.645 -> I can see that the FizzBuzz service has 100 percent of its method is tested,
136.25 -> but only 50 percent of the lines.
138.965 -> When I open the FizzBuzz service class again,
142.685 -> notice the red and green bars along the side of the source file.
147.125 -> Green represents lines that had been executed by
150.44 -> my test and red indicates lines that are not executed by my test.
155.68 -> It makes sense that my test for multiples of three executed lines 12,
161.395 -> 14, and 15, but not the rest of the method.
165.365 -> Let's go back and run the whole test for coverage now.
171.11 -> We can see that all of my tests pass and now we're up to 87 percent line coverage,
179.19 -> but not quite 100 percent.
181.305 -> Let's see what's missing. Everything in FizzBuzz is covered except for line
186.42 -> 19 that's because none of our test
189.38 -> checked numbers that are not a multiple of three or five.
193.055 -> That requirement wasn't mentioned in the comments and so we missed it.
197.765 -> This is fairly common and it's exactly why
200.72 -> unit tests can help clarify requirements for future developers.
205.205 -> Why don't we add a method to complete our test coverage?
210.275 -> We'll make a parameterized test that passes in
213.26 -> some integers that are not multiples of three or five,
218.21 -> and we will assert that the return value
221.72 -> is equal to the integer value of the number we pass in.
225.08 -> Now, when we rerun our test for coverage,
227.9 -> we'll be able to see that we've
230.03 -> achieved 100 percent line coverage of our FizzBuzz service.
234.845 -> An inevitable question with code coverage is what percent coverage should be aimed for?
239.93 -> There are a lot of different opinions on
242 -> this subject but I'm going to take the position that
244.73 -> code coverage is not a goal itself and
247.52 -> so there's no particular number you should strive for.
251.075 -> Code coverage is a tool that helps you evaluate if your test miss anything but it's not
256.58 -> a substitute for making sure that
258.335 -> all your requirements and boundary conditions are tested.
262.36 -> Consider our tests for the FizzBuzz service.
265.665 -> Even with 100 percent coverage we tested no unusual inputs.
270.605 -> We didn't test negative numbers,
272.66 -> we didn't test zero or very large numbers.
275.515 -> It's not a complex method and so the testing we did gives us a decent idea
279.98 -> how it works but 100 percent coverage doesn't mean we didn't miss anything.
285.11 -> There are also some methods that do not require code coverage,
289.115 -> like getters and setters,
290.9 -> or perhaps a default constructor.
293.315 -> Insisting on 100 percent coverage or any arbitrary amount of coverage risks
298.79 -> the creation of unnecessary tests that add noise and give a false sense of security.
304.745 -> Use code coverage to help identify any holes
307.76 -> in what you planned to test and focus on writing
310.46 -> good unit tests that meet
312.035 -> our other recommendations and cover all the requirements of your program.
Source: https://www.youtube.com/watch?v=0l6HL3c-vbs