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
[Coveralls.io](https://coveralls.io/) support for node.js. Get the great coverage reporting of coveralls.io and add a cool coverage button (like the one above) to your README.
6
+
[Coveralls.io](https://coveralls.io/) support for Node.js. Get the great coverage reporting of coveralls.io and add a cool coverage button (like the one above) to your README.
Add the latest version of `coveralls` to your package.json:
12
-
```
13
+
14
+
```shell
13
15
npm install coveralls --save-dev
14
16
```
15
17
16
18
If you're using mocha, add `mocha-lcov-reporter` to your package.json:
17
-
```
19
+
20
+
```shell
18
21
npm install mocha-lcov-reporter --save-dev
19
22
```
20
23
21
24
## Usage:
22
25
23
-
This script ( `bin/coveralls.js`) can take standard input from any tool that emits the lcov data format (including [mocha](http://mochajs.org/)'s [LCov reporter](https://npmjs.org/package/mocha-lcov-reporter)) and send it to coveralls.io to report your code coverage there.
26
+
This script `bin/coveralls.js` can take standard input from any tool that emits the lcov data format (including [mocha](https://mochajs.org/)'s [LCOV reporter](https://npmjs.org/package/mocha-lcov-reporter)) and send it to coveralls.io to report your code coverage there.
24
27
25
28
Once your app is instrumented for coverage, and building, you need to pipe the lcov output to `./node_modules/coveralls/bin/coveralls.js`.
26
29
27
-
This library currently supports [travis-ci](https://travis-ci.org/) with no extra effort beyond piping the lcov output to coveralls. However, if you're using a different build system, there are a few environment variables that are necessary:
28
-
* COVERALLS_SERVICE_NAME (the name of your build system)
29
-
* COVERALLS_REPO_TOKEN (the secret repo token from coveralls.io)
30
+
This library currently supports [Travis CI](https://travis-ci.org/) with no extra effort beyond piping the lcov output to coveralls. However, if you're using a different build system, there are a few environment variables that are necessary:
31
+
32
+
-`COVERALLS_SERVICE_NAME` (the name of your build system)
33
+
-`COVERALLS_REPO_TOKEN` (the secret repo token from coveralls.io)
30
34
31
35
There are optional environment variables for other build systems as well:
32
-
* COVERALLS_SERVICE_JOB_ID (an id that uniquely identifies the build job)
33
-
* COVERALLS_RUN_AT (a date string for the time that the job ran. RFC 3339 dates work. This defaults to your
34
-
build system's date/time if you don't set it.)
35
-
* COVERALLS_PARALLEL (more info here: https://docs.coveralls.io/parallel-build-webhook)
- Use the following to run tests and push files to coveralls:
39
-
```sh
40
-
jest --coverage --coverageReporters=text-lcov | coveralls
41
-
```
42
-
Check out an example [here](https://github.com/Ethan-Arrowood/harperdb-connect/blob/master/.travis.yml) which makes use of Travis-CI build stages
-`COVERALLS_SERVICE_JOB_ID` (an id that uniquely identifies the build job)
38
+
-`COVERALLS_RUN_AT` (a date string for the time that the job ran. RFC 3339 dates work. This defaults to your build system's date/time if you don't set it.)
39
+
-`COVERALLS_PARALLEL` (more info here: <https://docs.coveralls.io/parallel-build-webhook>)
- Use the following to run tests and push files to coveralls:
45
+
46
+
```sh
47
+
jest --coverage --coverageReporters=text-lcov | coveralls
48
+
```
49
+
50
+
Check out an example [here](https://github.com/Ethan-Arrowood/harperdb-connect/blob/master/.travis.yml) which makes use of Travis CI build stages
Instrumenting your app for coverage is probably harder than it needs to be (read [here](http://www.seejohncode.com/2012/03/13/setting-up-mocha-jscoverage/)), but that's also a necessary step.
66
+
Instrumenting your app for coverage is probably harder than it needs to be (read [here](http://seejohncode.com/2012/03/13/setting-up-mocha-jscoverage//)), but that's also a necessary step.
67
+
68
+
In mocha, if you've got your code instrumented for coverage, the command for a Travis CI build would look something like this:
57
69
58
-
In mocha, if you've got your code instrumented for coverage, the command for a travis build would look something like this:
59
70
```sh
60
71
YOURPACKAGE_COVERAGE=1 ./node_modules/.bin/mocha test -R mocha-lcov-reporter | ./node_modules/coveralls/bin/coveralls.js
61
72
```
62
-
Check out an example [Makefile](https://github.com/cainus/urlgrey/blob/master/Makefile) from one of my projects for an example, especially the test-coveralls build target. Note: Travis runs `npm test`, so whatever target you create in your Makefile must be the target that `npm test` runs (This is set in package.json's 'scripts' property).
73
+
74
+
Check out an example [Makefile](https://github.com/cainus/urlgrey/blob/master/Makefile) from one of my projects for an example, especially the test-coveralls build target. Note: Travis CI runs `npm test`, so whatever target you create in your Makefile must be the target that `npm test` runs (This is set in package.json's `scripts` property).
Add a coveralls script to "scripts" in your `package.json`:
87
99
88
-
```javascript
100
+
```json
89
101
"scripts": {
90
102
"test": "nodeunit test",
91
103
"coveralls": "jscoverage lib && YOURPACKAGE_COVERAGE=1 nodeunit --reporter=lcov test | coveralls"
@@ -100,29 +112,32 @@ Run your tests with a command like this:
100
112
npm run coveralls
101
113
```
102
114
103
-
For detailed instructions on requiring instrumented code, running on Travis and submitting to coveralls [see this guide](https://github.com/alanshaw/nodeunit-lcov-coveralls-example).
115
+
For detailed instructions on requiring instrumented code, running on Travis CI and submitting to coveralls [see this guide](https://github.com/alanshaw/nodeunit-lcov-coveralls-example).
Client-side JS code coverage using [PhantomJS](https://github.com/ariya/phantomjs), [Mocha](http://mochajs.org/) and [Blanket](https://github.com/alex-seville/blanket):
107
-
-[Configure](http://mochajs.org/#running-mocha-in-the-browser) Mocha for browser
108
-
-[Mark](https://github.com/deepsweet/poncho#usage) target script(s) with `data-cover` html-attribute
118
+
119
+
Client-side JS code coverage using [PhantomJS](https://github.com/ariya/phantomjs), [Mocha](https://mochajs.org/) and [Blanket](https://github.com/alex-seville/blanket):
120
+
121
+
-[Configure](https://mochajs.org/#running-mocha-in-the-browser) Mocha for browser
122
+
-[Mark](https://github.com/deepsweet/poncho#usage) target script(s) with `data-cover` HTML attribute
@@ -133,28 +148,31 @@ variable set and tap will automatically use `nyc` to report
133
148
coverage to coveralls.
134
149
135
150
### Command Line Parameters
151
+
152
+
```shell
136
153
Usage: coveralls.js [-v] filepath
154
+
```
137
155
138
156
#### Optional arguments:
139
157
140
-
-v, --verbose
141
-
142
-
filepath - optionally defines the base filepath of your source files.
158
+
-`-v`, `--verbose`
159
+
-`filepath` - optionally defines the base filepath of your source files.
143
160
144
161
## Running locally
145
162
146
-
If you're running locally, you must have a `.coveralls.yml` file, as documented in [their documentation](https://coveralls.io/docs/ruby), with your `repo_token` in it; or, you must provide a `COVERALLS_REPO_TOKEN` environment-variable on the command-line.
163
+
If you're running locally, you must have a `.coveralls.yml` file, as documented in [their documentation](https://docs.coveralls.io/ruby-on-rails#configuration), with your `repo_token` in it; or, you must provide a `COVERALLS_REPO_TOKEN` environmentvariable on the command-line.
147
164
148
165
If you want to send commit data to coveralls, you can set the `COVERALLS_GIT_COMMIT` environment-variable to the commit hash you wish to reference. If you don't want to use a hash, you can set it to `HEAD` to supply coveralls with the latest commit data. This requires git to be installed and executable on the current PATH.
149
166
167
+
## Contributing
168
+
169
+
I generally don't accept pull requests that are untested, or break the build, because I'd like to keep the quality high (this is a coverage tool after all!).
170
+
171
+
I also don't care for "soft-versioning" or "optimistic versioning" (dependencies that have ^, x, > in them, or anything other than numbers and dots). There have been too many problems with bad semantic versioning in dependencies, and I'd rather have a solid library than a bleeding edge one.
I generally don't accept pull requests that are untested, or break the build, because I'd like to keep the quality high (this is a coverage tool afterall!).
159
-
160
-
I also don't care for "soft-versioning" or "optimistic versioning" (dependencies that have ^, x, > in them, or anything other than numbers and dots). There have been too many problems with bad semantic versioning in dependencies, and I'd rather have a solid library than a bleeding edge one.
0 commit comments