DEV Community

loading...

Code Coverage

Deepak Gupta
DevOps Engineer/Practitioner. Here to share resourceful and ready to go knowledge about OS(Linux), SCM, CI/CD, Configuration Management, Clusterization and Orchestration
・2 min read

An introduction to code coverage

In this blog, you'll learn what is code coverage, in what stages does it help us and what is the need of it??

Code Coverage is a parameter under software testing which tells you the no. of lines of code that are successfully validated under a test procedure, which in turn, help us in analyzing/verifying the quality of our software code.

To Calculate :

Code Coverage Percentage = (Number of lines of code executed by a testing algorithm/Total number of lines of code in a system component) * 100.

Code coverage criteria :

1.Function Coverage -- The functions in the source code that are called and executed at least once.

2.Statement Coverage -- The number of statements that have been successfully validated in the source code.

3.Path Coverage -- The flows containing a sequence of controls and conditions that have worked well at least once.

4.Branch or Decision Coverage -- The decision control structures (loops, for example) that have executed fine.

5.Condition Coverage -- The Boolean expressions that are validated and that executes both TRUE and FALSE as per the test runs.

Alt Text

So does it mean higher the code-coverage % better is the code quality of your software program.

Noooh!!!

If we take 100% code coverage for any software program it says no bug, no defect and indicates that the test cases have covered all the criteria and requirements of software application.

But in this case we are clueless and blank to evaluate if the test case has met all range of possibilities or not, did the test cases cover the incorrect requirements or might have missed any important ones??!!

So if we see the software product is built on 100 % irrelevant code coverage then undoubtedly we're gonna compromise on quality.

Then what should we focus on?? Our focus should be on writing test scripts that aren’t fuzzy. Don’t focus on achieving 100% coverage , focus on how the analysis can be clubbed out with your robust test scripts which are gonna cover every functional and non-functional area of source code.

Where I Read

Feel free to connect and correct if wrong anywhere.

Discussion (0)