{"id":6912,"date":"2023-01-10T13:06:39","date_gmt":"2023-01-10T05:06:39","guid":{"rendered":"https:\/\/slash.bravefactor.com\/?post_type=resources&#038;p=6912"},"modified":"2024-01-22T17:34:51","modified_gmt":"2024-01-22T09:34:51","slug":"the-two-approaches-to-test-coverage","status":"publish","type":"resources","link":"https:\/\/slash.co\/articles\/the-two-approaches-to-test-coverage","title":{"rendered":"The two approaches to test coverage"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Test coverage, let\u2019s begin by outlining what we mean by this. Test coverage is a method for measuring how many codes have been covered by your test cases. Simple, right? We think so too! Though why is something so simple, this important? It\u2019s important to emphasize that although unit testing can increase the amount of time it takes to implement a feature, the overall time requirements balance out over the product\u2019s release cycle due to increased quality and maintainability.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Using code-coverage tools to help check the total percentage that you cover all over your code base is key.<\/span><\/p>\n<p><img decoding=\"async\" class=\"size-medium wp-image-7106 aligncenter lazyload\" data-src=\"https:\/\/slash.co\/wp-content\/uploads\/2023\/01\/1-1-385x102.png\" alt=\"1\" width=\"385\" height=\"102\" title=\"\" src=\"data:image\/svg+xml;base64,PHN2ZyB3aWR0aD0iMSIgaGVpZ2h0PSIxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==\" style=\"--smush-placeholder-width: 385px; --smush-placeholder-aspect-ratio: 385\/102;\"><\/p>\n<p style=\"text-align: center;\"><i><span style=\"font-weight: 400;\">Coverage Metrics<\/span><\/i><\/p>\n<p><span style=\"font-weight: 400;\">There are four key coverage metrics that you must know to understand test coverage. Those four metrics are as follows:<\/span><\/p>\n<p><strong>Statements<\/strong><span style=\"font-weight: 400;\"> &#8211; <\/span><span style=\"font-weight: 400;\">The number of statements that have been executed at least once during the unit tests. In some programming languages, there can be multiple statements in a single line of code.<\/span><\/p>\n<p><strong>Branch<\/strong> <span style=\"font-weight: 400;\">&#8211; The number of control statements which conditions have been fulfilled at least once during the unit tests.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Branch coverage provides more precise results than code coverage because it helps cope with code coverage\u2019s shortcomings. Instead of using the raw number of code lines, this metric focuses on control statements, such as if and switch statements. It shows how many of such control statements are traversed by at least one test in the suite.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Each condition can be counted as one; however, there are some cases where you don\u2019t have the explicit \u201celse\u201d so there are some tricks you can use to count the number of branches.\u00a0<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><span style=\"font-weight: 400;\">Control statements<\/span>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"3\"><span style=\"font-weight: 400;\">if\u2026 else (even is implicit else)<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"3\"><span style=\"font-weight: 400;\">switch counts as branch<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"3\"><span style=\"font-weight: 400;\">ternary operators<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"3\"><span style=\"font-weight: 400;\">else if count as 2 branches<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><span style=\"font-weight: 400;\">Default parameters<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Please note, not all loops count as a branch and branch is the most important metric.\u00a0<\/span><\/p>\n<p><strong>Functions<\/strong><span style=\"font-weight: 400;\"> &#8211; <\/span><span style=\"font-weight: 400;\">The functions that have been called at least once during the unit tests. <\/span><span style=\"font-weight: 400;\">One function counts as one, if the file has two functions and you test the file, you\u2019ll get 100%.<\/span><\/p>\n<p><strong>Lines<\/strong><span style=\"font-weight: 400;\"> &#8211; <\/span><span style=\"font-weight: 400;\">The number of lines of code that have been executed at least once during the unit tests.<\/span><\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" class=\"size-medium wp-image-7107 aligncenter\" src=\"https:\/\/slash.co\/wp-content\/uploads\/2023\/01\/2-1-385x235.png\" alt=\"2\" width=\"385\" height=\"235\" title=\"\"><\/p>\n<p><span style=\"font-weight: 400;\">The uncovered line metric simply clues you into which lines of code are not covered in the test. Now, the statement metric represents instructions that have been executed at least once during the unit tests.\u00a0Lines represent code lines that have been executed at least once during the unit tests. Often you will see the statement and line metrics have the same percentage. This is a reflection of coding itself; that being, typically you only write one statement per line. Though naturally there are exceptions like when using two statements per line for a declaration.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The final question on yours and everyone\u2019s minds is\u2026 How many tests should we cover? Should we do 100% test coverage or\u2026?\u00a0Good questions and to answer these, let\u2019s consider two schools of thought to approach test coverage.<\/span><\/p>\n<h2><span style=\"font-weight: 500;\">Benefits<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Let\u2019s wrap-up with a quick review of the benefits of test coverage. For one, i<\/span><span style=\"font-weight: 400;\">t helps improve the quality of your software, and also ensures you do not ship bug-filled software to your end-user. Secondly, code refactoring is helpful for the developers because in unit testing when considerable change is applied you have to ensure all the previous functionality is working. Thirdly it benefits adding new features as when this is done you have to ensure that all the existing features don\u2019t break.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Fourthly, documentation helps as it includes documentation for your function so other team members can see how the function will work by viewing the unit testing. Fifthly, early bug discovery allows you to have a proactive stance and stay out in front of those troublesome obstacles to development. This in turn leads to the sixth benefit of simplifying the debugging process. Here instead of testing and brand applications over and over, you just need to have one unit test that can do the debugging for you.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Finally this culminates into developer happiness as once you have more unit tests, developers will gain confidence when launching the product. A confident developer is a happy developer who is capable of producing stunningly clean code for a superb product!<\/span><\/p>\n<h2><span style=\"font-weight: 500;\">Approach #1<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The goal is not to score the highest percentage for test coverage, rather we want to test that which is isolated and doesn&#8217;t require a mock function. If the tests require a lot of mock functions, the test is not so effective. However, this can be ideal for small dev teams short on manpower. So in this case, unit testing is deployed. Now the total test coverage may be around 30%, but you\u2019re only testing the very unit functions that don\u2019t require some mockup. Consider that if you try to reach a higher percentage of test coverage, you will need to maintain and refactor more code.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Therefore, unit testing is part of your code base, increasing the need to do more integration testing. How the implementation works is not the key point as your focus should be on the final result. Remember that you\u2019re only testing functions which do not require any mocking up.<\/span><\/p>\n<h2><span style=\"font-weight: 500;\">Approach #2<\/span><\/h2>\n<p><span style=\"font-weight: 400;\">On the flip side to approach #1, we have the idea that the more coverage, the better chance of finding bugs. This approach is well suited for a larger dev team with the manpower and resources to run all these tests. A simple goal is to measure the percentage of the code covered by the tests. However, this is not a bulletproof approach that guarantees the discovery of any and all bugs; hence the existence of approach #1.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">You could easily have close to 100% code coverage with bad tests that don\u2019t mean anything. Low coverage is a bad sign; high coverage is a possible sign that things are better, but never perfect. This approach hamstrings the team\u2019s ability to implement integrate testing\u00a0due to spending too much time on test coverage.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In the end, regardless of the test approach you select, testing not only needs to be done, but is inherently key to the success of the code you\u2019ve written. Both tracks lead you to testing and aim to ensure clean code at the terminus!<\/span><\/p>\n","protected":false},"featured_media":11867,"parent":0,"template":"","resource-topic":[],"resource-type":[43],"class_list":["post-6912","resources","type-resources","status-publish","has-post-thumbnail","hentry","resource-type-articles"],"_links":{"self":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resources\/6912","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resources"}],"about":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/types\/resources"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/media\/11867"}],"wp:attachment":[{"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/media?parent=6912"}],"wp:term":[{"taxonomy":"resource-topic","embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resource-topic?post=6912"},{"taxonomy":"resource-type","embeddable":true,"href":"https:\/\/slash.co\/wp-json\/wp\/v2\/resource-type?post=6912"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}