You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sbt-scoverage is a plugin for SBT that integrates the scoverage code coverage library. Find out more about [scoverage](https://github.com/scoverage/scalac-scoverage-plugin).
5
-
6
-
Join the [scoverage](http://groups.google.com/group/scala-code-coverage-tool)
7
-
google group for help, bug reports, feature requests, and general
@@ -46,46 +38,40 @@ To generate the coverage reports run
46
38
$ sbt coverageReport
47
39
```
48
40
49
-
Coverage reports will be in `target/scoverage-report`. There are HTML and XML reports. The XML is useful if you need to programatically use the results, or if you're writing a tool.
50
-
51
-
If you're running the coverage reports from within an sbt console session (as
52
-
opposed to one command per sbt launch), then the `coverage` command is sticky. To
53
-
turn it back off when you're done running reports, use the `coverageOff` command or reset `coverageEnabled` with `set coverageEnabled := false`.
54
-
55
-
Sample project with scoverage in both sbt and maven - [the scoverage samples project](https://github.com/scoverage/sbt-scoverage-samples).
56
-
57
-
## Notes on upgrading to version 1.3.0
58
-
59
-
* The object containing the keys has changed from nested to top level so you might need to adjust the import. It's also an auto plugin now, so you might not need the import at all.
60
-
* There is an issue syncing the binary with the sbt-plugin-releases repo, so in the meantime add `resolvers += Resolver.url("scoverage-bintray", url("https://dl.bintray.com/sksamuel/sbt-plugins/"))(Resolver.ivyStylePatterns)` to your build.
61
-
62
-
## Notes on upgrading to version 1.0.0
41
+
Coverage reports will be in your `target/scala-<scala-version>/scoverage-report`
42
+
directory. There are HTML and XML reports. The XML is useful if you need to
43
+
programatically use the results, or if you're writing a tool.
63
44
64
-
If you are upgrading from 0.99.x then you must remove the `instrumentSettings` from your build.sbt or Build.scala, as that is no longer needed.
45
+
**NOTE**: If you're running the coverage reports from within an sbt console
46
+
session (as opposed to one command per sbt launch), then the `coverage` command
47
+
is sticky. To turn it back off when you're done running reports, use the
48
+
`coverageOff` command or reset `coverageEnabled` with `set coverageEnabled :=
49
+
false`.
65
50
66
-
Next, the keys have been renamed slightly. The new names begin with coverageXXX, eg coverageExcludedPackages and some have had their full name changed. You can see a full list of keys by opening the object ScoverageKeys.
51
+
### Multi project reports
67
52
68
-
## Multi project reports
53
+
By default, scoverage will generate reports for each project separately. You can
54
+
merge them into an aggregated report by using the following:
69
55
70
-
By default, scoverage will generate reports for each project seperately. You can merge them into an aggregated report by invoking `sbt coverageAggregate`.
71
-
72
-
(Note, you must do this after all the coverage data is complete as a separate command, so you cannot do `sbt coverage test coverageAggregate` (at least until a way around this is found).)
56
+
```
57
+
$ sbt coverageAggregate
58
+
```
73
59
74
-
(You must have first run `sbt coverageReport` for `coverageAggregate` to work. It aggregates over the sub-projects' report xml rather than over the coverage data directly.)
60
+
**NOTE**: You do not need to run `coverageReport` before `coverageAggregate`; it
61
+
aggregates over the sub-projects' coverage data directly, not the report xml.
75
62
76
-
## Exclude classes and packages
63
+
###Exclude classes and packages
77
64
78
-
You can exclude classes from being considered for coverage measurement by providing semicolon-separated list of
79
-
regular expressions.
65
+
You can exclude classes from being considered for coverage measurement by
66
+
providing semicolon-separated list of regular expressions.
The regular expressions are matched against the fully qualified class name, and must match the entire string to take effect.
87
-
88
-
Any matched classes will not be instrumented or included in the coverage report.
72
+
The regular expressions are matched against the fully qualified class name, and
73
+
must match the entire string to take effect. Any matched classes will not be
74
+
instrumented or included in the coverage report.
89
75
90
76
You can also mark sections of code with comments like:
91
77
@@ -95,67 +81,67 @@ You can also mark sections of code with comments like:
95
81
// $COVERAGE-ON$
96
82
```
97
83
98
-
Any code between two such comments will not be instrumented or included in the coverage report.
84
+
Any code between two such comments will not be instrumented or included in the
85
+
coverage report.
99
86
100
-
## Minimum coverage
87
+
###Minimum coverage
101
88
102
-
Based on minimum coverage, you can fail the build with the following keys
89
+
Based on minimum coverage, you can fail the build with the following keys:
103
90
104
91
```scala
105
92
coverageMinimum :=80
106
93
coverageFailOnMinimum :=true
107
94
```
108
95
109
-
These settings will be enforced when the reports are generated.
110
-
If you generate an aggregate report using `coverageAggregate` then these settings will apply to that report.
96
+
These settings will be enforced when the reports are generated. If you generate
97
+
an aggregate report using `coverageAggregate` then these settings will apply to
98
+
that report.
111
99
112
-
## Highlighting
113
-
114
-
If you are using Scala 2.11.1 or less, then highlighting will not work (due to this bug which was fixed in 2.11.2 https://github.com/scala/scala/pull/3799). In that case you must disable highlighting by adding the following to your build:
115
-
116
-
```scala
117
-
coverageHighlighting :=false
118
-
```
100
+
## Trouble-shooting failing tests
119
101
120
-
## Failing tests
121
-
Scoverage does a lot of file writing behind the scenes in order to track which statements have been executed.
122
-
If you are running into a scenario where your tests normally pass, but fail when scoverage is enabled, then the culprit can be one of the following:
102
+
scoverage does a lot of file writing behind the scenes in order to track which
103
+
statements have been executed. If you are running into a scenario where your
104
+
tests normally pass, but fail when scoverage is enabled, then the culprit can be
105
+
one of the following:
123
106
124
107
* timing issues on futures and other async operations, try upping the timeouts by an order of magnitude.
125
108
* tests are run in a sandbox mode (such as with `java.security.PrivilegedAction<T>`), try running the tests outside of the sandbox.
[Codacy](https://www.codacy.com) integrates with your favorite coverage tool to provide an in-depth overlook of your project status. Scoverage information can be integrated into Codacy through the [sbt-codacy-coverage plugin](https://github.com/codacy/sbt-codacy-coverage).
118
+
[Codacy](https://www.codacy.com) integrates with your favorite coverage tool to
119
+
provide an in-depth overlook of your project status. scoverage information can
If you have an open source project then you can add code coverage metrics with the excellent website https://coveralls.io/ Scoverage will integrate with coveralls using the [sbt-coveralls](https://github.com/scoverage/sbt-coveralls) plugin.
125
+
If you have an open source project then you can add code coverage metrics with
126
+
the [Coveralls](https://coveralls.io/). scoverage will integrate with coveralls
127
+
using the [sbt-coveralls](https://github.com/scoverage/sbt-coveralls) plugin.
136
128
137
-
### Plugin for SonarQube
129
+
### Codecov
138
130
139
-
If you want to visually browse statement coverage reports then use this [plugin for SonarQube](https://github.com/RadoBuransky/sonar-scoverage-plugin).
140
-
It allows you to review overall project statement coverage as well as dig deeper into sub-modules, directories and
141
-
source code files to see uncovered statements. Statement coverage measurement can become an integral part of your
142
-
team's continuous integration process and a required quality standard.
131
+
You can integrate with [Codecov](https://about.codecov.io/) easily sending your
132
+
reports there via your CI. You can see an example of this here in
0 commit comments