Predicting Class Testability using Object-Oriented Metrics

1. Predicting Class Testability using Object-Oriented Metrics M. Bruntink and A. van Deursen Presented by Tom Chappell

2. Goal • To assess the capability of certain object-oriented metrics to predict class testability • Useful for: • Planning • Design • Monitoring

3. Source Code Metrics • LOCC – Lines of Code Per Class • The number of lines of source code,not including blank lines and comments • FOUT – Fan Out • The number of classes used by a class

4. Source Code Metrics • NOM – Number of Methods • Counts the number of new methods declared by a class • Does not count methods inherited from superclass, even if overridden

5. Source Code Metrics • NOF – Number of Fields • Counts the number of new fields(class variables and member variables) declared by a class • Does not count fields inherited from superclass

6. Source Code Metrics • RFC – Response for Class • The number of methods in a class (including inherited methods) plus the number of methods of other classes invoked by that class

7. Source Code Metrics • DIT – Depth of Inheritance Tree • The number of ancestors of a class • NOC – Number of Children Classes • Counts only the immediate subclasses,not all descendents

8. Source Code Metrics • WMC – Weighted Methods per Class • The total of McCabe’s Cyclomatic Complexity for each method implemented by the class • Cyclomatic Complexity is the number of distinct execution paths in the method

9. Source Code Metrics • LCOM – Lack of Cohesion of Methods • 0: every field of the class is used byevery method of the class (Lower Bound) • 1: every field of the class is used by one method of the class • n / (n-1): no field of the class is used by any of the n methods of the class (Upper Bound) • Defined for classes with at least 1 field andat least 2 methods

10. Test Suite Metrics • dLOCC – Lines of Code for [Test] Class • The number of lines of source code in a test class, not including blank lines and comments • dNOTC – Number of Test Cases • The number of times that a test classcalls a JUnit assert method.

11. Case Studies • DocGen • Commercial documentation generator • 90,000 lines of Java code • 640 classes (138 with associated test classes) • Developed with XP methodology • Coding standard: method not allowed to exceed 12 lines

12. Case Studies • Apache Ant • Open Source build tool (similar to “make”) • 170,000 lines of Java code • 887 classes (111 with associated test classes)

13. Results • Strong Predictors of High dLOCC(Lines of [Test] Class Code): • RFC – Response for Class • LOCC – Lines of [Source] Class Code • FOUT – Fan Out • WMC – Weighted Method Count • NOM – Number of Methods • NOF – Number of Fields

14. Results • Strong Predictors of High dNOTC(Number of Test Cases): • RFC – Response for Class(DocGen Only) • LOCC – Lines of [Source] Class Code(DocGen Only)

15. Results • LCOM – Lack of Cohesion of Methods • Moderately correlated to dLOCC/dNOTC in Ant • Much less strongly correlated in DocGen • DocGen’s “12 lines per method” coding standard increases LCOM

16. Comments • Choice of Correlation Statistic • The authors use Spearman’s rank-order correlation coefficient ( rs ) • This measures only rank-order correlation (“the class with the 13th-highest number of LOCC had the 13th-highest dLOCC”) • The degree that a change in LOCC would cause to change in dLOCC is not measured

17. Comments • Suggested Metric: %Interface Fan Out • Measures the percentage of fan-out references that refer to interfaces,rather than to classes • Designing APIs to use interfaces makes classes more flexible and makes it easier for the unit test to set up a test environment using test stub classes that implement required interfaces

18. Questions?