Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / DevOps / testing

100 % code coverage

4.83/5 (19 votes)
6 Sep 2013CPOL3 min read 56.5K  
I am a big fan of unit testing and I am big opponent of over unit testing.

 

 I am a big fan of unit testing and I am big opponent of over unit testing.

 

Image 1

 

Some managers proudly blow up and boast about their code quality by showing a 100% code coverage screen as shown below. As a developer I was wondering is it really essential that your unit test shows 100% code coverage to prove that you have best code.   

If you are new to code coverage read this :- What is code coverage ? 

Because  to achieve 100% code coverage the developer has to put lot of efforts writing those unit test cases and ensuring all paths are covered which is definitely time consuming.

Image 2

 

So if 100% code coverage is not really worth, is 80% more real or is 75% coverage more balanced?.

Let us just go back to basics and ask one basic  testing question to ourselves.

Why do we testing?

We do testing because there is some complex code out there which can lead to defects. So we need to make sure that the complex code has a test case, its tested and the defects are fixed before its live.

Can you see the highlighted word complex?.  Yes, that’s what should drive you code coverage. In other words ensure that your test covers complex part of your code.

Ok , so define complex, because  complex for someone can be simple for some one. Now the next question is how we judge complexity of code?.

Does lot of lines of code means, the code is complex?.

Does lot of IF and Select case, for loops makes code complex ?. So should cyclomatic complexity be taken as a base line?.  In case you are new to cyclomatic complexity read from here http://computerauthor.blogspot.in/2013/09/what-is-cyclomatic-complexity-c-testing.html

Does lot of inheritance, aggregation and composition makes a code complex?

I think it should be a metric which should account all of the above. “Maintainability index” metrics is one of the kind which is thrown by visual studio code metrics analyzer. Maintainability index metrics takes in to account all the above factors and comes out with a number which lies in between 0 to 100 , more the value the better it is.

 

<o:p> 

Image 3

 

So I would like to see lower maintainability index code covered 100%.  For instance in the below report I would like see the “Calculate” method having 100 % test coverage , because the maintainability is 65. But the “Cancel” method is having 80% maintainability index value so probably I would exclude it.

Image 4

<o:p> 

If you see the “Cancel” method code it is just initialization of lot of variables. So testing this method will just add more effort to my unit testing with no great quality improvement. 

public void Cancel()
{
            Num1 = 0; 
            Num2 = 0;
            Operation = ""; 
            Pie = 3.14;
            Num5 = 0;
            Operation1 = "";
            Num20 = 0;
            Numx = 0;
            OperationStart = "";
            PieMore = 3.145;
            Num6 = 0;
            Operationnew = "";
} 

Now look at the “Calculate” method its complex, lot of “IF” conditions etc. So we would like to ensure that every code branch of this method is executed. 

public int Calculate()
        {
            if (Operation.Length == 0)
            {
                throw new Exception(" Operation not sepecified");
            }
                if (Operation == "+")
                {
                    return Num1 + Num2;
                }
                else if (Operation == "-")
                {
                    return Num1 - Num2;
                }
                else
                {
                    return Num2 * Num1;
                }
                return 0;
 
        } 

So rather than carving for 100 % code coverage, I would follow the below process:-

·         Understand which of my code has less maintainability index, must be the bench mark can start somewhere below than 80 %.

·         Review that part of the code and check if it’s something complex and crucial.

·         If crucial and important then this block of code should be covered.

So rather than saying “We want 100 % code coverage”, we can rephrase saying “We would like to see 100% code coverage for complex and crucial code”.

Sorry if I hurted any test coverage purist’s by this article.

For Further reading do watch  the below interview preparation videos and step by step video series.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)