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:
- Architectural metrics: Dependency level, Fan-in, Fan-out, and Ext user.
These measure the complexity of relationships such as method calls, inheritance,
or variable usage.
- Component complexity metrics: Attributes, Methods, Statements, and V(g).
These metrics measure the complexity of the control flow of the source code.
- Test coverage metrics: Line and Tests. Coverage metrics indicate whether
the code needs further testing. Line shows the percentage of lines of code
covered by tests. Tests indicates the number of tests directly using a method
of the class.
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.