Code coverage in Testing

Question

I have recently started using TDD or u can say testing for my project and there i found some new thing(new thing for me) which is called "Code coverage" which shows how much your code is covered during the testing process. And as much i know most of the seniors use to say its not possible to have 100% code coverage or its not good practice to get 100% code coverage. This thing keeps me wondering like how this code coverage works i mean they covers code on which bases? please tell the main usage of Testing.

I am attaching image of code coverage with this question.

Answer 1

Actually, 100% code coverage is possible but depends a bit on the language:

• Sometimes import or include statements are not taken into account, so then 100% is not possible
• It depends mostly on the tool used (like lines above are ignored or not)
• if 100% is not reached because of not testing exceptions, than this is not good. Also bad weather tests should be performed

About the usefullness of 100% code coverage:

• Of course, the higher, the better
• At least all lines should be tested, especially in less strong tyep languages like Python. In C/C# etc, the compiler will find more, but even then a high code coverage is welcomed

Even 100% code coverage does not mean the code is perfect:

• That a line is tested, does not mean that the complete line is executed (like only half of an if statement in 'if x && y' ... if x results in False, y is not checked anymore.
• Due to loops and the order of the program flow, values of variables can be different, resulting in exceptions. Therefore, it is also important to check combination of values.

Addition:

In case 100% code coverage is not wanted (because everything takes time, thus money), first focus on the high risk areas in the code. Skip trivial methods at first and start with complicated/high risk functions.

Also it is important to use design patterns or a code structure to 'help' unit testing:

• Split the (G)UI from the logic code. (G)UI code is mostly harder to unit test.
• Use small functions, to ease unit testing (and to make a clear design).
• Make code as loosely connectable as possible. This results in a clear design and also helps easy unit testing (unneeded to use lots of stubs).
• Think about a testing 'framework', e.g. to use stubs including injection of values to the stubs to test both good and bad weather scenarios.

Answer 2

First, in order to understand the value of code coverage you have to understand what you want to achieve with it. Code coverage helps you determine the quality of your program code, e.g. is it robust or prone to errors, is it cohesive or does it have hidden dependencies, is it easy to change or not, etc.

Code with high code coverage tends to be better code, but it is no guarantee that it is good code. This is because the code quality strongly depends on how well your test cases are build, e.g. if you are testing your intended behavior well, or for false or destructive inputs, for corner cases or other special cases, etc. If your test suite is badly written, you can still achieve high (or 100%) code coverage, but your code will be of low quality.

Second, the reason why most experienced developers will tell you 100% test coverage is not required or even a bad practice is that the time you need to invest to make code coverage 100% is better invested in a more complete test suite. It will usually even be easier to achieve 100% code coverage with a poorly written test suite than with a well designed one.

Third, because you will (almost) never have a complete test suite, just because I don't know lots of people who can consider all possible cases that code may go wrong, you should develop an urgency to amend you test suits continuously (not infinitely) rather than settling on the false felling of full code coverage.

I hope this view on code coverage helps you make it more useful for you.