benbria / coffee-coverage Goto Github PK
View Code? Open in Web Editor NEWIstanbul and JSCoverage-style instrumentation for CoffeeScript files.
License: MIT License
Istanbul and JSCoverage-style instrumentation for CoffeeScript files.
License: MIT License
I'm wondering if this is compatible with istanbul?
https://github.com/gotwarlost/istanbul
I'm trying to do something like: istanbul cover --report html _mocha
Hi,
Is there a way to ignore files that I don't want it's statistics in coverage-coffee.json?
Now it seems to always collect coverage information from all files of my project and store in coverage-coffee.json output file – regardless of the path passed to mocha for test.
For example, consider the following directory structure:
After running my tests with mocha (and requiring coffee-coverage), it collected statistics from files in root (Gruntfile.coffee), from src/ and from grunt_tasks/. I think this is an incorrect behavior since I only want data from files within src/. Any ideias on this?
Thank you!
node v4.2.6
when
./node_modules/.bin/mocha -R spec --compilers coffee:coffee-script/register --require ./coffee-coverage-loader
I get
(node) child_process: options.customFds option is deprecated. Use options.stdio instead.
/home/kfm/code/ds3g/readin/node_modules/coffee-coverage/lib/coffeeCoverage.js:279
throw new CoverageError("Could not parse " + fileName + ": " + err.stack);
^
CoverageError: Could not parse /home/kfm/code/ds3g/readin/node_modules/halbert/node_modules/browserify/node_modules/browser-resolve/test/fixtures-coffee/foo.coffee: SyntaxError: unexpected //
at Object.exports._runInstrumentor (/home/kfm/code/ds3g/readin/node_modules/coffee-coverage/lib/coffeeCoverage.js:279:13)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentCoffee (/home/kfm/code/ds3g/readin/node_modules/coffee-coverage/lib/coffeeCoverage.js:237:24)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentFile (/home/kfm/code/ds3g/readin/node_modules/coffee-coverage/lib/coffeeCoverage.js:219:21)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (/home/kfm/code/ds3g/readin/node_modules/coffee-coverage/lib/coffeeCoverage.js:196:27)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (/home/kfm/code/ds3g/readin/node_modules/coffee-coverage/lib/coffeeCoverage.js:182:23)
coffee-coverage does not load the instrumented files if I use rewire to load UUT.
So the coverage summary reports a very low percentage of coverage and I feel so bad.
Here an example:
report:
https://dl.dropboxusercontent.com/u/4661756/wssjs-coverage.html
class:
https://github.com/ufojs/wssjs/blob/master/src/websocket.coffee
test:
https://github.com/ufojs/wssjs/blob/master/test/websocket.test.coffee
Hi there,
currently coffee-coverage uses prepublish
as script hook. Unfortunately this isn't only run pre publish, as the name suggests, but also after npm install
. This slows down build processes including coffee-coverage unnecessarily.
It would be great if you could use a different hook or use something like in-publish to ensure it doesn't run during npm install
.
Best,
Daniel
https://gist.github.com/vird/f2fe643820cf79c35de9feb97531436b
temp workaround for me coffee-script -> iced-coffee-script in coffeeCoverage.js (not solves problem, but makes my code working)
Hello,
Firstly, coffee-coverage
is awesome. Thanks for the fantastic tool. Let me also apologize if this turns into a serious "is it me?" bug report, but I'm totally stumped and have burned way too many hours on this.
I've got two major coffeescript projects: one that uses CommonJS and one that does not. For the app built out in the CommonJS style, coffee-coverage
works beautifully and we could not do without it. It was easy to setup, and we use it to extract 3 different report types.
I've had a different experience, however, getting it setup in our non-CommonJS app... despite everything appearing to be setup correctly, the generated report always claims that not a single line was run.
In this app, each module is exposed on window
, scoped to our namespace such as window.NA.MyModule
. Since the modules are not CommonJS-ified, we can't very well require
them in our test files, so I followed your static compilation tutorial. Our setup uses jsdom
to create a headless browser and load a single (concatenated) file that contains all the instrumented JS. After days of struggling with things I believe that I have a setup that should - but refuses to - work. My setup is using gulp
, spawning tasks with gulp-shell
for coffeeCoverage
and mocha
, using the html-cov
reporter.
As I said, my tests are running fine: they pass or fail as one would expect, and a coverage report is generated at the specified path. My problem is that the coverage report is always empty, claiming that no code was run whatsoever and showing a 0 for every single line...
Here are the details of my setup:
src
gulp
task runs coffeeCoverage
as a shell task on the entire directory, exporting instrumented files to _tmp
with this command...$ coffeeCoverage --path abbr -i ./js/test/init.js ./path/to/coffeescript ./path/to/_tmp
... which generates a copy of the directory structure found in src
at _tmp
- with all coffeescript files replaced by instrumented js files - and an init.js
file that looks like it should
gulp
task concatenates all the instrumented files into one large file so it can easily be loaded into a jsdom
browser context for testingtask 'build-test', ['coffee-coverage'], ->
gulp.src 'path/to/instrumented/files/'
.pipe concat 'test-app.js'
.pipe dest 'path/to/test/dir'
gulp
task runs mocha
as a shell command with the following options (note that I'm requiring the init.js
file that coffeeCoverage
generated)$ mocha --compilers coffee:coffee-script/register --reporter html-cov --bail --require js/test/init.js js/test/spec_init.coffee js/test/testclass_spec.coffee > coffee-coverage-results/coverage.html
spec_init
file first, which creates a jsdom
instance that loads the concatenated, instrumented js file in the <head>
of the DOM inside a before
call# Inside spec_init.coffee
before (next) ->
config =
html: '<body></body>'
scripts: ['path/to/concatenated/instrumented/js/file']
features:
FetchExternalResources: ['script']
ProcessExternalResources: ['script']
done: (error, window) ->
if error then console.log error.stack ? error
root.NA = window.NA
next()
jsdom.env config
)
jsdom
instance: modules are instantiated and destroyed, events are triggered and heard, and then a coverage report appears in the specified folder that says not a single line was runSorry for pestering you with this, but is it my setup? Or is there something wrong with the plugin while using this type of setup...
Thanks very much
Hi,
First off, this is by far the best Coffescript code coverage tool I've found for Node! Massive kudos!
I'm however having a rather annoying issue with exclude
not seeming to work at all. My implementation is as straight-forward as it gets:
require("coffee-coverage").register(
path: "relative"
basePath: __dirname
exclude: ["some-dir"]
)
Everything inside some-dir
still gets included in the output for some reason. Any ideas would be greatly appreciated!
I have my repo setup so that potato.coffee
compiles in the same directory to potato.js
. When potato.js exists, my code coverage always shows 0% for potato.coffee. If I remove potato.js, code coverage for potato.coffee
goes back to a correct percentage.
example structure where I'm running into issues
project
│ README.md
└───lib
│ │ potato.coffee
│ │ potato.js <- when this exists, coverage of project/lib/potato.coffee is always 0%
│ when it doesn't exist, coverage of project/lib/potato.coffee is normal
└───test
│ │
│ └───lib
│ │ │ potato.coffee
│ │ │ potato.js
Here's my project/test/mocha.opts in case it matters:
--compilers coffee:coffee-script/register
--require coffee-coverage/register-istanbul
--reporter spec
--recursive
--growl
test/lib/potato.coffee
I am using
mocha --require coffee-coverage/register \
--compilers coffee:coffee-script/register \
-R html-cov --bail test/ > coverage.html
How can I tell it to check all files in the src
directory for coverage?
I wonder whether you could integrate Travis-CI into your repository?
Sorry to say, but the function introduced for sparing us the extra global variable will actually break the code. Having instrumented a coffee-script file I tried running that file using node instrumented.js.
The following error came up
(function(export) {
^^^^^^
SyntaxError: Unexpected reserved word
at Module._compile (module.js:439:25)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3
I will provide you with a fix for that ASAP.
Adding require 'coffee-coverage/register-istanbul'
inside Cakefile
’s runTests
throws errors for the files with new features added in CoffeeScript 2 (note filenames):
CoverageError: Could not parse documentation/examples/jsx.coffee:
[stdin]:9:4: error: missing / (unclosed regex)
</aside>
^
CoverageError: Could not parse documentation/examples/object_spread.coffee:
SyntaxError: unexpected ...
CoverageError: Could not parse documentation/examples/type_annotations.coffee:
SyntaxError: unexpected : string
And import
or export
statements, added in 1.11, still aren’t supported (#82):
CoverageError: Could not compile documentation/examples/modules.coffee after instrumenting:
SyntaxError: import statements must be at top-level scope
Is support for Literate CoffeeScript planned?
What would need to be done?
Hi,
I have the following Test file in mocha/chai
chai = require 'chai'
should = chai.should()
require '../cov/task'
Task = require '../task'
describe 'Task Instance', ->
task1 = task2 = null
it 'should have a name', ->
task1 = new Task 'afeed the cat'
task1.name.should.equal 'feed the cat'
it 'should be inititally incomplete', ->
task1.status.should.equal 'incomplete'
it 'should be able to complete', ->
task1.complete().should.be.true
task1.status.should.equal 'complete'
it 'should be able to be dependent on another task', ->
task1 = new Task 'wash dishes'
task2 = new Task 'dry dishes'
task2.dependsOn task1
task2.status.should.equal 'dependent'
task2.parent.should.equal task1
task1.child.should.equal task2
and my model is
class Task
constructor: (@name)->
@status = 'incomplete'
complete: ->
@status = 'complete'
true
dependsOn: (@parent)->
@parent.child = @
@status = 'dependent'
exports = module.exports = Task
The command listed didn't work for me at all:
mocha --require coffee-coverage/register --reporter html-cov > coverage.html
This, on the other hand, did:
mocha --require coffee-coverage/register --compilers coffee:coffee-script/register -R html-cov --bail test/ > coverage.html
My source is in src/
and tests are in test/
.
For tests executed using Mocha
When coding in CoffeeScript
With the release of 1.11, CoffeeScript has begun moving toward the ES2015+ standard. In particular, CoffeeScript now supports ES2015 import/export directives.
These do not play well with coffee-coverage right now, producing errors like this:
> mocha --recursive --compilers coffee:coffee-script/register --require coffee-coverage/register-istanbul
/Users/wcj/dev/ormojo/node_modules/ormojo/node_modules/coffee-coverage/lib/coffeeCoverage.js:321
throw new CoverageError("Could not compile " + fileName + " after instrumenting: " + err.stack);
^
CoverageError: Could not compile /Users/wcj/dev/ormojo/node_modules/ormojo/src/Backend.coffee after instrumenting: SyntaxError: export statements must be at top-level scope
Presumably, export and import statements should simply be ignored when instrumenting, as they are meant to be declarative.
I am currently working on a PR that adds both boolean expression (if x == 1 and y ==2) branch coverage data as well as function invocation coverage data, similarly to what JSCover provides.
Differently from JSCover, the solution I have in mind would keep track of function names, e.g. "1"...N, and provide require source location information in the collected data. JSCover, from what I have figured out so far, just uses the function names (0...N) to collect data on their invocation, making it difficult for external tools, for example vows, to figure out on the whereabouts of the function in the original source.
Let me hear if this would be a useful addition to this tool. I know that it is rather "complicated" given the existing AST, but I believe that I am on the right track, so to say...
Hi, I forked this repo to add support for CJSX / coffee-react. I haven't made any changes yet, but tests are failing. I wonder if maybe I don't have something installed that I need?
tail of results from npm build && mocha
:
77 passing (2s)
7 failing
Istanbul tests should find if branch with no else:
first statement
{
"end": {
at Context. (test/istanbul/test.coffee:345:66)
Istanbul tests should find switch/case branches:
first statement
{
"end": {
at Context. (test/istanbul/test.coffee:468:66)
Istanbul tests should find functions:
first statement
{
"end": {
at Context. (test/istanbul/test.coffee:589:66)
Istanbul tests should find multi-line functions:
first statement
{
"end": {
at Context. (test/istanbul/test.coffee:683:66)
Istanbul tests should find functions in a class:
class statement
{
"end": {
at Context. (test/istanbul/test.coffee:786:66)
Istanbul tests should find name of anonymous class:
class fn
expected - actual
"column": 4
"line": 1
}
}
at Context. (test/istanbul/test.coffee:864:59)
Coverage tests should handle nested recursion correctly:
AssertionError: expected 5 to equal 10
-5
+10
at Context. (test/tests.coffee:107:27)
bwilkerson@IT-SEA14730-MBP:/projects/zulily/coffee-coverage$ npm -v/projects/zulily/coffee-coverage$ node -v
4.1.2
bwilkerson@IT-SEA14730-MBP:
v7.5.0
bwilkerson@IT-SEA14730-MBP:~/projects/zulily/coffee-coverage$ mocha -v
error: unknown option `-v'
bwilkerson@IT-SEA14730-MBP:~/projects/zulily/coffee-coverage$ mocha --version
3.2.0
While the pragma feature is cool, these comments will be retained in the generated code:
Block comments, which mirror the syntax for block strings, are preserved in the generated code.
From my experiments with coffedoc and the "AST" written out by the coffee compiler, OTOH I think that that all documentation will be associated with the node immediately following that documentation.
Would it not be better to parse that documentation instead of leaking these pragmas into the generated code?
I would love to have support for coffee-react (.cjsx) files. I may even be willing to submit a pull request if someone provide some insight into how coffee-coverage works.
Hi,
When I run the mocha, it shows the all the test cases passes. But when I run through the code coverage, it shows as 0% coverage.
This is the command I use.
"mocha --recursive --compilers coffee:coffee-script/register -r should -r simock -r test/register-handlers.coffee -R html-cov test/unit_test/ > build/coverage.html"
My register-handlers.coffee looks like this,
require("coffee-coverage").register(
{
path: "relative"
, basePath: __dirname + '/../src'
, exclude: ['lib/api/calls/', 'app.coffee']
, initAll: true
}
).
I am not sure why, but it shows all the codes with line number in the html file. But with 0% coverage and 381 SLOC.
Could you please help me with this.
Thanks,
Raghu
Trying to switch from a static compilation approach to the register
approach in the README, I can't find my way beyond this issue:
ELLIOTTCABLE@FANNIE ~/Documents/Code/Paws.js (windows-compatible-build)
$ COVERAGE=true ./node_modules/.bin/mocha --require Library/register_coverage.js --reporter html-cov --compilers 'coffee:coffee-script/register' Test/BLAH.tests.coffee
c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:408
throw new CoverageError("Could not parse " + fileName + ": " + err.sta
^
CoverageError: Could not parse n\b\n\b\t\f\foo.coffee: [stdin]:1:1: error: unexpected //
// blank file
^^
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentCoffee (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:408:15)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentFile (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:356:21)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:334:27)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:318:23)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:318:23)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:318:23)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:318:23)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:318:23)
at CoverageInstrumentor.exports.CoverageInstrumentor.CoverageInstrumentor.instrumentDirectory (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:318:23)
at Object.exports.register (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-coverage\lib\coffeeCoverage.js:92:18)
at Object.<anonymous> (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\Library\register_coverage.js:3:31)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\coffee-script\lib\coffee-script\register.js:45:36)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at files (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\mocha\bin\_mocha:278:3)
at Array.forEach (native)
at Object.<anonymous> (c:\Users\ELLIOTTCABLE\Documents\Code\Paws.js\node_modules\mocha\bin\_mocha:277:10)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3
register_coverage.js
is copied pretty much verbatim from the README:
// Register coffee-coverage if coverage is enabled.
if(process.env['COVERAGE']) {
require('coffee-coverage').register({
path: 'abbr',
basePath: require('path').resolve(__dirname+'/..'),
exclude: ['/Library', '/Executables', '/Test', '/node_modules', '/.git'],
initAll: true }); }
Big fan of coffee-coverage, thanks. Have a backbone SPA grunt-mocha/grunt-mocha-phantomjs project that has an html page including all tests via script tag for the browserify-coffee-coverage'd tests. Bundle looks good but can't wrap my head around how to get the mocha run's coverage info out of the page. Alternative: browserify-istanbul writes this to a window.coverage variable and expects a web hook to write the contents out to a file for later istanbul report. This cannot generate an html coverage report because the coverage info references coffee files, but they don't match the transpiled javascript line numbers (other reports work OK). I would love a more CoffeeScripty solution and have a little time to spend on it... any pointers?
Currently trying to run istanbul tests with electron-mocha but am getting 0% coverage when it should be ~50%. Willing to do a PR myself if I can get pointed in the right direction.
My coffee-coverage-loader.coffee
looks like this:
coffeeCoverage = require "coffee-coverage"
coverageVar = coffeeCoverage.findIstanbulVariable()
writeOnExit = if coverageVar == null then "#{__dirname}/coverage/coverage-coffee.json" else null
coffeeCoverage.register
instrumentor: "istanbul"
basePath: "#{__dirname}/src/"
exclude: [
"*cli.coffee"
"*conf.coffee"
]
coverageVar: coverageVar
writeOnExit: writeOnExit
initAll: true
and I've tried all manner of globs for the exclude paths. For this library I've just got one file I want to instrument, and a -cli.coffee
that I would like to ignore. My mocha.opts
looks like this:
--compilers coffee:coffee-script/register
--require coffee-coverage-loader.coffee
--require mocha.conf.coffee
The problem could be because of istanbul ignoring the basePath
, but I'm not sure.
I'm using the given npm test
command from the Travis CI tutorial.
I also tried using an .istanbul.yml
file with no luck, mostly because I wasn't sure which options applied to instrumenting coffeescript...
I just find this confusing in your package.json
"main": "./lib/coffeeCoverage",
"bin": {
"coffeeCoverage": "./bin/coffeecoverage"
Any good reason to use both? Great useful lib otherwise! :)
How would I use coffee-coverage with nodeunit?
I really don't know why this happens.
I use a shellscript to run the tests:
"$PWD"/node_modules/.bin/mocha \
-b \
--compilers coffee:coffee-script/register \
--require coffee-coverage/register-istanbul \
--require should \
--reporter spec \
--timeout 120000 \
--slow 300 \
"$@"
You can see all the code here
The problem is that --require coffee-coverage/register-istanbul
line throw an Error related with the coverage folder:
✓ release a new version and hook pre releases plugins in order (163ms)
16 passing (300ms)
Failed to write coverage data Error: ENOENT, no such file or directory 'coverage/'
at Error (native)
at Object.fs.mkdirSync (fs.js:747:18)
at exports.mkdirs (/Users/josefranciscoverdugambin/Projects/bumped/bumped/node_modules/coffee-coverage/lib/utils/helpers.js:43:14)
at process.<anonymous> (/Users/josefranciscoverdugambin/Projects/bumped/bumped/node_modules/coffee-coverage/lib/register.js:116:11)
at process.emit (events.js:107:17)
at process.exit (node.js:600:17)
at done (/Users/josefranciscoverdugambin/Projects/bumped/bumped/node_modules/mocha/bin/_mocha:406:32)
at afterWrite (_stream_writable.js:361:3)
at _stream_writable.js:349:9
at process._tickCallback (node.js:355:11)
the strange thing is that the folder doesn't exist before I run the script (good) and after the exceptions exists.
Any idea of what happens?
reproduce:
Q = require 'bluebird'
readFile = Q.promisify (aPath, done)->
if aPath == 'c'
data = 'ok'
else
err = new Error('no such file')
done(err, data)
Q.reduce ['a', 'b', 'c', 'd'], (content, file)->
console.log file, content
if !content
content = readFile(file).caught(->)
return content
, null
.then (content)->
console.log 'content=', content
the result should be:
a null
b undefined
c undefined
d ok
content= ok
But after injected:
a null
b 0
c 1
d 1
content= 1
FYI. I'm using coffee-coverage with CucumberJS as the test runner. This worked fine for me with a small hack to get around a CucumberJS issue.
./node_modules/.bin/cucumberjs \
--require node_modules/coffee-coverage/register-istanbul.js \
--require $path_root/features \
--compiler coffee:coffee-script/register $*
My application is a Node REST-like API, with the application running in the same process as the test runner. I would imagine that instrumenting code coverage for the more typical Cucumber use case -- feature tests with Selenium browser automation -- would be difficult because the SUT runs in a different process from the runner. However I suppose JSDom could possibly work instead of Selenium for getting code coverage from tests.
Hello, odd bug here:
sourceStat.isDirectory()
@ https://github.com/benbria/coffee-coverage/blob/master/src/coffeeCoverage.coffee#L193
leads to
TypeError: Cannot read property 'isDirectory' of null
In some odd and not solidly reproducible cases where a ls
returns a directory that doesn't actually exist (exists returns true but stat returns null) I've noticed this when using Atom editor also. I'm running Windows and node 0.12.
It's a very rare edge-case but maybe a quick null check?
Noticed it with the current version of Coffee-Coverage 0.6.2
Here's the sample code:
if true
console.log "foo"
else if true
console.log "bar"
With coffee 1.6.2 and lower, we'd instrument tree lines here (before the if, and before the two console.logs.)
With coffee 1.6.3, we also try to add instrumentation between the "else" and the "if", which obviously breaks things.
Simple test file:
for a in [1,2]
i = 100
console.log(a)
After running coffeeCoverage test.coffee test.js
js-file is generated:
/* ... */
(function() {
var a, i, len, ref;
_$jscoverage["test.coffee"][1]++;
ref = [1, 2];
for (i = 0, len = ref.length; i < len; i++) {
a = ref[i];
_$jscoverage["test.coffee"][2]++;
i = 100;
_$jscoverage["test.coffee"][3]++;
console.log(a);
}
}).call(this);
And there is a bug: i
variable is used in loop, although it is in original coffee source. Loop will exit after first iteration in this case.
After converting by coffee -c test.coffee
it seems ok:
// Generated by CoffeeScript 1.9.1
(function() {
var a, i, j, len, ref;
ref = [1, 2];
for (j = 0, len = ref.length; j < len; j++) {
a = ref[j];
i = 100;
console.log(a);
}
}).call(this);
It appears that:
x = (fn) ->
### !pragma coverage-skip-block ###
console.log "foo"
will not cause Istanbul to ignore the enclosing function. This is unexpected behavior.
I would like to provide glob patterns in exclude which are resolved with minimatch.
Right now I can't exclude files of the form '*_spec.coffee'
Hey there,
Thanks for making such a fantastic project! Just a quick question -- I'm setting up a existing large project that formerly compiled code in order to get coverage so that it works with coffee-coverage. However, I'm finding that the report generated shows little to no actual coverage at all, while the compiled report was quite high and the project is tested thoroughly. I have followed instructions exactly, and it's not erroring out, just giving an incorrect report. The one thing I am not including is the --recursive
flag, as it's not needed to run my test suite. I tried including this, but then mocha tried to run some of the fixtures included in the tests folder and errored.
Is the --recursive
flag necessary to generate correct coverage? If not, what further information could I provide to make this incorrect coverage issue easier to shed light on? And if so, how do people typically deal with fixtures being run as tests with the recursive flag?
Thanks again!
Invoking coffeecoverage with the -c parameter set to for example coverage will produce instrumented sources that still use the _$jscoverage variable name, ignoring the user provided name.
I will provide a PR for this ASAP.
When placing a JavaScript label in CoffeeScript in front of a loop like this:
`loopLabel: //`
for item in someArray
...
the instrumentation will insert a line similar to
_$jscoverage[".\\somefile.coffee"][12]++;
between the label and the loop head, thus generating invalid JavaScript:
loopLabel: //;
_$jscoverage[".\\somefile.coffee"][12]++;
for (_i = 0, _len = someArray.length; _i < _len; _i++) {
item = someArray[_i];
...
Hi if i try to create a custom loader it fails because coffee-coverage cannot be required.
The file (and the whole lib folder) is missing.
Hi,
I am having trouble using coffee-coverage together with gulp/mocha/istanbul.
It works fine if I run things from the commandline as described in your documentation.
./node_modules/.bin/mocha test/test.js
./node_modules/.bin/istanbul report
The reports now list that my main target file has 88% coverage and there is a detailed report.
If I try to run it through gulp though
// gulp.js
mocha = require('gulp-mocha');
istanbul = require('gulp-istanbul');
...
gulp
.src('test/test.js')
.pipe(mocha())
.pipe(istanbul.writeReports());
// test/test.js
require('coffee-script/register');
require('coffee-coverage/register-istanbul');
require('./test-coffee.coffee'); // my actual tests
It reports 100% code coverage and lists 0 files.
There are also two coverage.json files listed.
coverage/coverage-coffee.json
coverage/coverage-final.json
The first one looks to have all the relevant date, the second one is an empty object literal.
The nearest I have been able to figure out is that coffee-coverage cannot find the $$cov.. variable which istanbul uses and so it writes out coverage-coffee, and then istanbul.writeReports ignores it.
Any help is appreciated.
In your README under "Static Compilation" you make mention of an argument called --initFile
. Using this option throws an error. In my terminal:
$ coffeeCoverage --initFile ./test/covered.js --path abbr ./src/polar/ops/orderform/gears/javascripts/
usage: coffeeCoverage [-h] [-v] [--verbose] [-b] [-c name] [-e filenames]
[-i file] [--path pathtype]
src dest
coffeeCoverage: error: Unrecognized arguments: --initFile.
I believe that -i
is what people should be using instead? The docs should be updated to call this out.
There is a bug in CoffeeScript 1.6.1 which brakes polymorphism. This issue is fixed in CoffeScript 1.6.2.
I'm having a hard time finding out where my Mongoose mapReduce
is going wrong, but the following error keeps occurring only when we have coffee-coverage
on:
[MongoError: exception: ReferenceError: _$coffeeIstanbul is not defined near '_$coffeeIstanbul['
And then just a path.
The command I am running is:
NODE_ENV=test mocha --require coffee-script/register --require coffee-coverage/register-istanbul --compilers coffee:coffee-script/register --require should --check-leaks --reporter spec test/unit/ test/e2e/
Am I missing something or is this a genuine bug?
So, my project includes a command-line executable; and to exercise that, I don't use JavaScript tests, but shell-script ones (specifically, using bats).
Can I generate coverage reports when not executing any JavaScript test suite at all, just an arbitrary executable (i.e. covering the results of my_exec --blah
)? More importantly, can I generate a single coverage report that covers multiple invocations (i.e. mocha my_tests
, and then later my_exec --blah
, my_exec --widget
)?
If this is possible: it'd be great to see this covered in your excellent new HOWTO writeups! Command-line apps are common in npm, and getting full coverage information for them would be ideal. (=
I want the code which is not in the src/ directory not to be counted in the coverage report, is there any way to do that?
coffee-coverage replaces require.extensions['.coffee'] to handle .coffee file compilations itself.
during tests, one of my submodules was requiring coffee-script/register, which led to the original coffee-script handler to compile the files, and coffee-coverage not instrumenting them.
I suspect that this is faced by other users as well. For example the user facing the issue #55 uses sprout which has this code https://github.com/carrot/sprout/blob/389799b5fa0eaa10e6f92d002dc1ee3ea3bc0660/lib/template.js#L21.
As you can see from the comments, when jwalton was trying to debug, the last instrumented file was a sprout.coffee.
There are two possible solutions:
I have used the first approach here https://github.com/abresas/register-coffee-coverage, a module that I use as a replacement for my mocha tests, passing --require register-coffee-coverage.
I would prefer this is fixed from coffee-coverage project itself, so I can throw away my wrapper-module .
Hello!
Thanks, this worked awesome. I took a different approach,
return unless process.env.COVERAGE is '1'
coffee = require 'coffee-script'
coverage = require 'coffee-coverage'
fs = require 'fs'
cover = new coverage.CoverageInstrumentor()
require.extensions['.coffee'] = (module, filename) ->
file = fs.readFileSync filename, 'utf8'
opts =
filename: filename
if filename.match /test/
content = coffee.compile file, opts
return module._compile content, filename
result = cover.instrumentCoffee filename, file
module._compile result.init + result.js, filename
with this file required in the mocha.opts
COVERAGE=1 mocha --reporter html-cov
This seems to work pretty nicely, not sure if I am using your library correctly!
Cheers for the good work...
Josh...
When running cake test on master, the following exception will be thrown:
Building
Testing
events.js:72
throw er; // Unhandled 'error' event
^
Error: spawn ENOENT
at errnoException (child_process.js:1000:11)
at Process.ChildProcess._handle.onexit (child_process.js:791:34)
Any idea why?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.