For technical reasons it might be necessary to exclude certain classes from code coverage analysis. The following options configure the coverage agent to exclude certain classes from analysis. Except for performance optimization or technical corner cases these options are normally not required.
- Excludes: A list of class names that should be excluded from execution analysis. The list entries are separated by a
colon (:)and may usewildcard characters (* and ?). (Default: empty) - Exclude classloaders: A list of class loader names that should be excluded from execution analysis. The list entries are separated by a
colon (:)and may usewildcard characters (* and ?). This option might be required in case of special frameworks that conflict with JaCoCo code instrumentation, in particular class loaders that do not have access to the Java runtime classes.(Default: sun.reflect.DelegatingClassLoader)
Warning: Use these options with caution! Invalid entries might break the code coverage launcher. Also do not use these options to define the scope of your analysis. Excluded classes will still show as not covered.
Resource Link:
The following examples all specify the same set of inclusion/exclusion patterns:
<filter includes="com.foo.*" excludes="com.foo.test.*, com.foo.*Test*" /><filter includes="com.foo.*" /> <filter excludes="com.foo.test.*, com.foo.*Test*" /><filter value="+com.foo.*, -com.foo.test.*, -com.foo.*Test*" />where myfilters.txt file contains these lines:
<filter excludes="com.foo.*Test*" file="myfilters.txt" />-com.foo.test.* +com.foo.*
Resource Link:
- Coverage filters
- I am certain that all of my classes are built with -g(debug='true') and yet EMMA still complains about missing debug info!
Ignore code coverage for unit tests in EclEmma
Preferences->Java->Code Coverage and set the "Only path entries matching" option to src/main/java - seems to work nicely.
No comments:
Post a Comment