Code complexity and code coverage analysis for IBM System Planning Tool

Comments

Analyzing code complexity and ensuring adequate code coverage are two ways to ensure quality of the code delivered as a result of a development project. For development projects that use agile methodology it's important to monitor the level of code complexity and code coverage in the day-to-day activities of project development and testing.

This article describes the steps required to configure the code complexity analysis tool and code coverage tool for the IBM System Planning Tool project in the Windows environment.

The IBM System Planning Tool is a web application tool that helps you to design system configurations according to your needs. Using this tool, you can configure a completely new system or can plan a system based on new workloads or existing performance data.

This project uses a Model-View-Controller (MVC) architecture in which:

  • A data model is used to store the run-time processed system objects
  • A view model is used to display the configured system information on a web page
  • A controller is used to control the communication between the data model and the view model

The following technologies are used in this project: Java™ technology, JavaServer Pages, JavaServer Faces, JavaScript, XML, and ANT. Java and J2EE project developers and testers are the main audience of this article.

Use this article as a guide to help you configure the code complexity and coverage analysis environment for your project. To accommodate your project, change the project files and paths in the examples to match your environment.

Code complexity analysis tool

The code complexity analysis tool calculates various metrics for the System Planning Tool project code during build cycles. The metrics generate warnings about the code complexity so that these issues can be corrected. This article describes how to use the Eclipse Metrics plugin to analyze the complexity of the code.

The code complexity tool provides metrics such as cyclomatic complexity, lines of code in method, number of statements, and number of levels in code.

Download and install the Eclipse Metrics plugin

The Eclipse Metrics plugin requires Eclipse to be running under JDK 1.5 or later.

  1. Download the Eclipse Metrics JAR file.
  2. Place the downloaded JAR file in the plugins directory for Eclipse.
  3. Restart Eclipse.

Enable and disable the Eclipse Metrics plugin

Based on the needs of your project, you can enable or disable the Eclipse Metrics plugin for each Java project. To enable the plugin, open the project's Properties, select the Metrics tab and check or uncheck Enable Metrics Gathering checkbox. Click OK to cause the project to recompile (if the project preferences are set to perform automatic builds) and to calculate metrics. If any metrics fall outside the specified range, warnings are generated and displayed in the Problems View and a mark is shown in the code block.

For example, to enable the Eclipse Metrics plugin in the System Planning Tool project, right click uSPT > Properties > Metrics and select the checkbox Enable Metrics Gathering, as shown in Figure 1.

Figure 1. Enable metrics
Select checkbox to enable the metrics gathering
Select checkbox to enable the metrics gathering

Set preferences

Open the Windows Preferences dialog and select the Metrics tab to perform the following actions:

  1. Enable or disable each metric.
  2. Set the maximum preferred values for each of the available metrics.
  3. Tune some of the metrics to match the needs of the project.

Click OK to cause the project to recompile (if the project preferences are set to perform automatic builds) and to recalculate the metrics. If any metrics fall outside the specified range, warnings are generated and displayed in the Problems View and a mark is shown in the code block.

Set the metrics preferences in the Complexity tab, as shown in Figure 2.

  • Select Cycolomatic Complexity and specify 4 for Upper Bound.
  • Select Weighted Methods Per Class and specify 40 for Upper Bound.
  • Select the options:
    • Include 'case' and 'default' statements
    • Include 'catch' clauses
    • Include 'ternary' operator
Figure 2. Set metrics preferences
Desired upper bound value setting for Complexity
Desired upper bound value setting for Complexity

Features of Eclipse Metrics

With the Eclipse Metrics plugin, you have access to several kinds of metrics:

  • Cyclomatic complexity: Indicates the number of linear segments (sections of code with no branches) in a method. Use this metric to determine the number of tests required to obtain complete coverage. This metric can also be used to indicate the psychological complexity of a method. For example, a method with no branches has a cyclomatic complexity of 1. This number is incremented whenever a branch is encountered.
  • Lines of code in method: Indicates the number of lines a method occupies. A line is determined by the presence of a newline character.
  • Number of statements: Represents the number of statements in a method. This is a more robust measure than lines of code because the lines of code can vary with respect to formatting conventions. Statements counted by this metric are break, continue, do, explicit constructor call, explicit super constructor call, for, if, return, switch, throw, try, catch, finally, while, and assignments.
  • Number of levels: Indicates the maximum number of levels of nesting in a method. A large number of levels increases complexity.

Metrics captured for the System Planning Tool project

Figure 3 shows the code complexity metrics that are collected for the project. In this particular method, the following metrics are collected:

  • Number of levels: 7
  • Lines of code in method: 84
  • Number of statements: 47
  • Cyclomatic complexity: 10
Figure 3. Metrics captured for System Planning Tool project
Project metrics displayed in Eclipse
Project metrics displayed in Eclipse

Code coverage tool

The code coverage tool measures the extent to which the source code of a program is tested by a particular test case or test suite. Knowing this measure helps the developer to add more test cases for the source code. This action greatly increases the code quality.

This article shows how to use the Eclipse tool EclEmma to analyze the coverage of the code.

Download and install EclEmma

EclEmma requires Eclipse 3.5 or later and Java 1.5 or later.

  1. From the Eclipse menu click Help > Eclipse Marketplace.
  2. Search for EclEmma.
  3. Click Install for the entry EclEmma Java Code Coverage.
  4. Complete the steps provided in the installation wizard.
  5. Include junit.jar in the project workspace.
  6. Restart Eclipse.

Capture code coverage for a single test case in the project

This section describes how to configure EclEmma to capture the coverage details for a single test case CCIN_test_cases in the System Planning Tool project.

To check the code coverage of CCIN_test_cases.java, go to Package Explorer and select the file CCIN_test_cases.java. Then right-click the file name and click Coverage As > Coverage Configurations, as shown in Figure 4.

Figure 4. Coverage configurations
Configure coverage in Eclipse by selecting file
Configure coverage in Eclipse by selecting file

In the next window, create a Java Application by specifying CCIN_test_cases as the Name and specify the following details in the Main tab, as shown in Figure 5.

  • Project: uTest
  • Main class: test.TestLoader
  • Select the checkbox Stop in main
  • Click Coverage
Figure 5. Coverage configuration – Main tab
Project and Main class setting under Main tab
Project and Main class setting under Main tab

On the Coverage tab all of the projects in the Eclipse workspace for the System Planning Tool (uLVT, uSPT, uSPT_MRI, and uTest) are selected by default. Therefore, the code coverage of that particular test case spans all these projects. To restrict the coverage check to include only certain projects, select only the following projects on the Coverage tab, as shown in Figure 6.

  • uLVT - src
  • uSPT – insulation/src
  • uSPT – web/src
  • uSPT_MRI
Figure 6. Coverage configuration – Coverage tab
Selection of analysis scope for SPT project
Selection of analysis scope for SPT project

On the Arguments tab, specify the following details, as shown in Figure 7.

  • Program arguments:
    	test/unit/fcresolution/information
    CCIN_test_cases
    -norecordings
  • VM arguments: Dcom.ibm.spt.fdate=20151231
Figure 7. Coverage configuration – Arguments tab
Specify Program arguments and VM arguments
Specify Program arguments and VM arguments

Click Apply and Coverage.

The tool runs the first test case (notice the test case output in the Console tab) and then collects coverage details of that test case and shows the details in the Coverage tab, as shown in Figure 8.

Figure 8. Coverage information – Project coverage
Covered, missed, total instructions for a project
Covered, missed, total instructions for a project

To request the code coverage of the test case, click uTest > CCIN_test_cases in the coverage data elements, as shown in Figure 9. This action shows the percentage of code that is covered in individual methods.

Figure 9. Coverage Information – Method coverage
Covered, missed, total instructions for a method
Covered, missed, total instructions for a method

Show the source code annotation

Various coverage details such as line, branch, and method coverage of the active coverage session can also be directly displayed in the Java source editors.

In the same Coverage output window, double-click a test case file. Notice the code lines highlighted with different colors, which indicate code coverage within the test case, as shown in Figure 10.

Figure 10. Source code annotation
Highlight covered code lines with different colors
Highlight covered code lines with different colors

Each color represents a particular meaning in the source code when coverage is captured for a particular test case.

  • Green: Lines of code that have full coverage.
  • Yellow: Lines of code that are partially covered (some instructions or branches are missed).
  • Red: Lines that have no coverage. The lines of code have not been run at all.

Coverage properties

The coverage metrics for various properties of code such as lines, branches, and instructions can be obtained for a particular test case after the launch of coverage.

For example, to check the coverage properties of test case CCIN_test_cases.java, go to Package Explorer, select that file, and then right-click Properties to see the Coverage tab. Coverage properties are listed as shown in Figure 11.

Figure 11. Coverage properties
Instructions, Branches, Lines, Methods covered
Instructions, Branches, Lines, Methods covered

You can also get the coverage information for all the test cases that exist in a test bucket or test suite for a particular project.

Conclusion

Code complexity and code coverage analysis are the two important quality metrics for any development project. This article gives detailed steps for how to configure code complexity and code coverage analysis tools for the IBM System Planning Tool. Eclipse Metrics and EclEmma plugins are used to gather the code complexity and code coverage details for the project, respectively. With the Eclipse Metrics plugin, a developer can obtain various code metrics such as cyclomatic complexity, lines of code in method, number of statements, and number of levels in code. With the EclEmma plugin, a developer or tester can obtain the information about the extent to which a particular set of code (or set of test cases in a test bucket or test suite) has been tested. The code coverage details can be obtained at a project level and at every method level. Using these development tools in every project in day-to-day development activities can greatly improve the quality and performance of any product.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=975899
ArticleTitle=Code complexity and code coverage analysis for IBM System Planning Tool
publish-date=07012014