Help:Code coverage in a nutshell
| Table of Contents | |
|---|---|
Code coverage analysis can help identify which tests do sufficiently well (qualitative statement limited to the classes and methods that are being tested) and indicates which of those have a high risk impact when changing its functionality (see CRAP) due to its dependency and cyclomatic complexity.
NPath complexity[edit]
Represents a number of acyclic execution paths, for more see here.
C.R.A.P[edit]
C.R.A.P. (Change Risk Analysis and Predictions) index is designed to analyze and predict the amount of effort, pain, and time required to maintain an existing body of code Pardon My French, But This Code Is C.R.A.P. (2) by Alberto Savoia
Two factors that are being considered when calculating the index:
- Code complexity as a representation of how many decisions paths exists in a method (see cyclomatic complexity)
- Test coverage of a method measured by how many decisions are testable and tested
Software metrics[edit]
While software metrics applied blindly might not sufficiently reflect the whole context of a class/method it nevertheless can indicate where effort is necessary (in terms of re-factoring) to ensure that code quality stays healthy and is maintainable over a period of time.
What contributes to a high index?[edit]
- Non existing tests
- A large number of paths (if, foreach etc.) that are executed during processing, multiplying the potential risk of unintended behaviour due to implicit decision chains
What about SMW ?[edit]
Most classes and methods prior SMW 1.9 have not been measured nor analysed in terms of its complexity (CRAP index) but the 1.9 release shows that certain classes do have a high CRAP index (some with over 5000 due to non existing tests and/or an inherent class complexity) which indicates a potential risk when those classes are re-factored or changed.
In order to ensure maintainability and testability, a class should aim for a CRAP index not higher than 30 as it allows for enough functional complexity to carry out specified tasks without the need to split classes in too many sub-classes while maintaining a low index.
See also[edit]
- TestCoverage by Marting Fowler
- PHPUnit and C.R.A.P index
- PHPUnit code coverage analysis
