Code Coverage Tutorial (Branch, Statement, Decision, FSM)

The ultimate goal of any software development company is to provide high-quality software. The software must be properly tested in order to reach this goal.

As a result, testing is an important aspect of the software development process. As a result, it's critical that the software generated be evaluated by the developer (during the unit testing phase) and then delivered to the QC team to be extensively tested to guarantee that it has few or no flaws.

Before being delivered to the actual test team for testing, the software is unit tested. This testing is done by the developer because it involves testing at the code level. This is done to guarantee that each component of the code being tested functions properly.

What is the definition of code coverage?

Code coverage is a metric that describes how thoroughly the program's source code has been tested. It's a type of white box testing that looks for sections of the software that aren't being tested by a set of test cases. It also constructs some test cases in order to boost coverage and determine a quantitative code coverage measure.

In most circumstances, the code coverage system collects data about the currently running program. It also combines this information with source code information to provide a report on the code coverage of the test suite.

Why Do We Require Code Coverage?

Code Coverage is important for a variety of reasons, some of which are stated below −

• When compared to software that does not have a good Code Coverage, it helps to ensure that the software has fewer errors.

• It indirectly aids in the delivery of better ‘quality software by assisting in the improvement of code quality.

• It is a metric that can be used to determine the effectiveness of a test (effectiveness of the unit tests that are written to test the code).

• It assists in identifying areas of the source code that might otherwise go unexplored.

• It aids in determining whether present testing (unit testing) is adequate and whether additional tests are required.

Why should you utilize Code Coverage?

Here are some of the most compelling reasons to use code coverage −

• It assists you in determining the effectiveness of test implementation.

• It provides a quantitative evaluation.

• It indicates how thoroughly the source code has been tested.

Original Source Code Structure

• Take two values, such as a=0 and b=1.

• Calculate the total of these two numbers.

• "This is the positive result," print if the sum is greater than 0.

• "This is the negative result," print if the sum is less than 0.

Methodologies

In this section, we'll go over the many ways for measuring Code Coverage that are/can be utilized.

To get to know these methodologies, let’s take a look at the below code snippet −

Add (int a, int b) {
   if (b > a) {
      b = b - a
      print b
   }
   if (a > b) {
      b = a – b
      print b
   }
   else print '0'
}

Statement Coverage

This methodology is a metric that determines if all possible executable statements in source code have been run at least once. It's a technique for ensuring that each line of source code is tested at least once.

While this may appear to be a straightforward task, it is important to proceed with caution while determining Statement Coverage. The reason for this is that based on the input values, a condition in a source code may or may not be executed. This would imply that testing would not cover all lines of code. As a result, various input value sets may be required to cover all such circumstances in the source code.

In the preceding source code, for example, if the input values are 2 and 3, the ‘Else' section of the code will not be run. The ‘If' part of the code, on the other hand, will not be run if the input values are of types 3 and 2. This means that our Statement Coverage would not be 100% with either set of data. In this scenario, we may need to run the tests with all three sets of data [(2, 3), (3, 2), (0, 0)] to ensure 100 percent Statement Coverage.

Function Coverage

This methodology measures the extent to which the functions included in the source code are covered during testing, as the name implies. During the test run, all functions in the source code are tested. Again, we must ensure that we test these functions for varied values in order to guarantee that the function is adequately tested.

There may be several functions in a source code file, and depending on the input values provided, a function may or may not be called. As a result, the goal of Function Coverage is to ensure that we have all of the functions required.

If our tests call the ‘Add' function even once in the source code above, we would refer to it as a full Function coverage.

Condition Coverage

Wherever we have a condition in the source code, the result is a Boolean value of true or false. The goal of condition coverage is to see if the tests cover both true and false values. When each occurring condition in the source code is assessed for both true and false states, the code's Condition Coverage is said to be complete.

For example, if value sets (2, 3) and (4, 2) are utilized in the following code, Condition Coverage will be 100%. When data sets (2, 3) are used, (b > a) becomes true and (a > b) becomes false. When using data set (4, 2), (b > a) evaluates to false, but (a > b) evaluates to true. As a result, both conditions have both true and false values covered. As a result, the Condition Coverage would be 100%.

Branch Coverage

This methodology seeks to make sure that each conditional structure's branch is performed in source code. For example, in the preceding code, the test should cover all of the ‘If' statements as well as any accompanying ‘Else' statements for 100% Branch Coverage.

For example, if value sets (2, 3), (4, 2), (1, 1) are utilized in the given code, Branch Coverage will be 100%. When data sets (2, 3) are used, the first ‘If' branch is run and (b > a). When data set (4, 2) is used, (a > b) evaluates to true, which causes the second ‘If' branch to be executed.

The ‘Else' branch then evaluates to true with the data set (1, 1) and is executed. As a result, 100% Branch Coverage is ensured.

Benefits of Branch Coverage

The following are some of the benefits of branch coverage testing −

• Allows you to validate all of the code's branches, ensuring that none of them lead to any abnormalities in the program's execution.

• The branch coverage method eliminates difficulties that arise as a result of statement coverage testing.

• Allows you to find places that aren't covered by other techniques of testing.

• It enables you to calculate a numerical measure of code coverage.

• Branch coverage does not take into account branches within Boolean expressions.

Coverage of Finite State Machines

The most difficult sort of code coverage method is finite state machine coverage. This is because it affects the design's behavior. This coverage approach requires you to count the number of time-specific states that are visited and transited. It also determines how many sequences a finite state machine contains.

Which Type of Code Coverage Should You Select?

This is without a doubt the hardest response to offer. In order to choose a coverage approach, the tester must first ensure that the requirements are met.

• There are one or more undetected faults in the code under test.

• The cost of a potential penalty,

• the cost of a damaged reputation,

• the cost of a missed sale, and so on.

• The more likely faults will result in costly production failures, the more severe the amount of coverage you should choose.

Benefits

As previously stated, it is an extremely valuable test metric for the following reasons −

• It aids in identifying portions of a source code that might otherwise go untested or discovered by the tests.

• It is useful for identifying used/dead code and thereby increasing code quality.

• Code Coverage can be used to determine the effectiveness of unit tests.

• These measurements can be used to deliver higher-quality software.

Drawbacks

• Code coverage still reports 100 percent coverage even if a certain feature is not implemented in the design.

• Code coverage does not allow us to tell whether we tested all possible values for a feature.

• Additionally, code coverage does not indicate how much or how well you have covered your logic.

• When a stated function isn't implemented or isn't included in the specification, structure-based approaches are unable to detect the problem.

Code Coverage Tools

Here, is a list that contains Important code coverage Tools −

Summary

• Code coverage is a metric that reflects how thoroughly the program's source code has been tested.

• It assists you in determining the effectiveness of test implementation.

• There are five different ways to measure code coverage. 1.) Coverage of Statement 2.) Condition Protection 3) Coverage of all branches 4) Coverage toggle 5) Coverage by the FSM

• Statement coverage entails running all of the source code's executable statements at least once. Decision coverage gives the true or false results of each Boolean expression.

• Every result from a code module is tested in the branch coverage.

• The variables or subexpressions in the conditional statement will be evaluated in this way.

• The most difficult sort of code coverage method is finite state machine coverage.

• To choose a coverage approach, the tester must consider the cost of a potential penalty, lost reputation, lost sale, and other factors.

• Code coverage indicates how thoroughly your test bench has exercised the source code. The term "functional coverage" refers to how well the design's functionality has been covered.

• Among the most popular code coverage tools are Cobertura, JTest, Clover, Emma, and Kalistick.

• You can use Code Coverage to add more test cases to your coverage.

• Code coverage does not tell you whether we tested all of a feature's conceivable values.

Vineet Nanda

Updated on: 17-Aug-2021

2K+ Views

Kickstart Your Career

Get certified by completing the course

Get Started