Static metrics

Detailed static analysis metrics of the component-under test (CUT) can help you decide how to prioritize your tests. There are metrics that analyze component architecture, component complexity, and test coverage.

Static metrics are displayed in the New Java™ Component Test wizard, after you have selected the source files that compose the CUT. At this stage, you can sort, hide, and show the data in order to determine the best test strategy:

Using metrics to plan your tests

You might find the following suggestions useful for planning your tests:
  • Concentrate on testing components that will provide the highest coverage rate. The Fan-out metric represents the number of uses of methods or attributes that are defined outside the class. This is a good indication of classes that have a high impact on coverage rate. Testing classes with a high Fan-out score without any stubbing will allow you to quickly test a large percentage of the code. On the other hand, strict unit testing on those classes (using stubs to isolate components) will require a lot of work to create many stubs.
  • Concentrate on testing components that are functionally critical. Look at metrics such as Fan-in, which is the number of public attributes plus the number of public methods in the class, or Ext User, which indicates the number of external components that use attributes or methods of the class. The higher these values, the greater the risk of regression if any changes are made to the class. These classes should therefore be thoroughly tested.
  • Concentrate on the most complex components. Complexity indicators are mainly the cyclomatic complexity number (V(g)) and the number of Statements in the code. Typically, V(g) varies between 1 and 10, where a value of 1 means the code has no branching.
  • Even if you test all of the methods of the classes individually, be sure to define class-level tests. This does not necessarily mean that you need to test each individual class. For example, if you have a few classes that are so tightly coupled that to test one class, you need to stub all the others, you might consider testing a small cluster of 3 to 10 classes together.
  • Identify the subsystems or large clusters that should be tested as a unit. A subsystem should be tested as a unit when it meets either of the following criteria:
    • You have classes with interdependencies that you need to deliver to another developer.
    • You have classes interacting together and with other classes that you have stubbed during your class-level testing.
    Use the Level indicator to evaluate the dependency level of a class in the call graph of the application.
  • Once a first series of tests has been performed, the line coverage rate (Line) and the number of tests that apply to a component (Tests) allow you to identify any components that have not yet been sufficiently covered by previous tests.

Related reference
Static metrics reference

Terms of use | Feedback
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.