4 ms·

Istanbul: A JavaScript code coverage tool written in JS

42 points by sebslomski 12y ago

joshuacc 12y ago
Istanbul has been a godsend for my company's JS-based projects. When paired with grunt-contrib-jasmine, it gives instant visibility into how much of the client-side app is actually under test, and gives everyone an incentive to keep improving coverage.
fittom 12y ago
Great tool, perfectly fits to the node.js ecosystem, lightweight and fast. However in case you use co-mocha[1] to test your generators, istanbul won't work properly, the generators in the reports are shown as uncovered. Therefore I made a mocha fork[2] and directly applied the changes from co-mocha to the source (instead of monkey patching); it solved the problem. [1] https://github.com/blakeembrey/co-mocha https://github.com/blakeembrey/co-mocha [2] https://github.com/tfitos/mocha https://github.com/tfitos/mocha
illumen 12y ago
This is a brilliant tool for those of us who test JavaScript. A bit of a hack, but it seems to work. It's also a reason why browsers should allow some sort of tracing API for JavaScript. I know V8 and Firefox do not expose the interface because they couldn't think of a decent enough use case to justify exposing the surface area of this code. This is the use case.
martin-adams 12y ago
In case it's useful for anyone, here is a gist of a gulpfile I use to use Istanbul to instrument my Node.js app, then run tests with Mocha and output the results: https://gist.github.com/medatech/76c6017cf55630b2db08 https://gist.github.com/medatech/76c6017cf55630b2db08
- jongleberry 12y ago
  or you could just write it as a single CLI command: https://github.com/strongloop/express/blob/master/package.json#L79 https://github.com/strongloop/express/blob/master/package.js...
avel 12y ago
For rails projects, if you use the teaspoon gem as test runner (https://github.com/modeset/teaspoon https://github.com/modeset/teaspoon), then you can easily get istanbul based coverage reports as well. It's a good way to see which paths your js tests take in a large project and pinpoint untested code.
TheTurkish 12y ago
Why did you name it Istanbul?
- ktt 12y ago
  > Why the funky name? > Since all the good ones are taken. Comes from the loose association of ideas across coverage, carpet-area coverage, the country that makes good carpets and so on... https://github.com/gotwarlost/istanbul#why-the-funky-name https://github.com/gotwarlost/istanbul#why-the-funky-name
  - Tloewald 12y ago
    It made me think of the Neil Simon song.
johnnymonster 12y ago
why is this popping up now? its quite an old project at this point.
gomathinayagam 12y ago
sample LCOA Report links is broken, http://gotwarlost.github.io/istanbul/public/coverage/std-lcov/index.html http://gotwarlost.github.io/istanbul/public/coverage/std-lco...
orkj 12y ago
I use this all the time. This is the command I use for coverage with mocha: ./node_modules/istanbul/lib/cli.js cover -- ./node_modules/mocha/bin/_mocha -R spec Always in my Makefile as make test-cov
jaegerpicker 12y ago
Ah that reminds me I wrote a coverage server for istanbul in node.js. It allows testem to send coverage statics across mutliple tests/runs to reported on. It's part of a whole test running package that I'm working on open sourcing that will allow testem (which is a great test runner if you don't mind running all of your tests in one big session) to run multiple suites of tests. For instance if you have a order app and an client management app and you want separate test runs to avoid any namespace collisions the project allows you to define handlebars based templates to define your suites and run each suite with testem one at a time. Anyway here is a gist of the coverage server if it's useful to anyone: https://gist.github.com/jaegerpicker/95c3900426d55eb9b857 https://gist.github.com/jaegerpicker/95c3900426d55eb9b857
sheetjs 12y ago
I'm a fan of mocha + blanket for coverage: https://github.com/alex-seville/blanket https://github.com/alex-seville/blanket The mocha integration is incredibly easy: mocha --require blanket -R html-cov # for html output
gcb4 12y ago
i have some projects where the meat is in a cross domain connector. no way to test it in units. only functional test in real browsers cut it. otherwise it's just red tape testing. there is zero coverage tool for this case, until browsers wake up and give me a decent Dev api like opera 12 allowed
tekromancr 12y ago
Wasn't this project originally called "Constantinople"?
- dragonwriter 12y ago
  Surely, the question you mean to ask is if it was originally called "Byzantium".

42 points by sebslomski 12y ago

Istanbul has been a godsend for my company's JS-based projects. When paired with grunt-contrib-jasmine, it gives instant visibility into how much of the client-side app is actually under test, and gives everyone an incentive to keep improving coverage.

fittom 12y ago

Great tool, perfectly fits to the node.js ecosystem, lightweight and fast. However in case you use co-mocha[1] to test your generators, istanbul won't work properly, the generators in the reports are shown as uncovered. Therefore I made a mocha fork[2] and directly applied the changes from co-mocha to the source (instead of monkey patching); it solved the problem. [1] https://github.com/blakeembrey/co-mocha https://github.com/blakeembrey/co-mocha [2] https://github.com/tfitos/mocha https://github.com/tfitos/mocha

illumen 12y ago

This is a brilliant tool for those of us who test JavaScript. A bit of a hack, but it seems to work. It's also a reason why browsers should allow some sort of tracing API for JavaScript. I know V8 and Firefox do not expose the interface because they couldn't think of a decent enough use case to justify exposing the surface area of this code. This is the use case.

martin-adams 12y ago

In case it's useful for anyone, here is a gist of a gulpfile I use to use Istanbul to instrument my Node.js app, then run tests with Mocha and output the results: https://gist.github.com/medatech/76c6017cf55630b2db08 https://gist.github.com/medatech/76c6017cf55630b2db08

jongleberry 12y ago
or you could just write it as a single CLI command: https://github.com/strongloop/express/blob/master/package.json#L79 https://github.com/strongloop/express/blob/master/package.js...

avel 12y ago

For rails projects, if you use the teaspoon gem as test runner (https://github.com/modeset/teaspoon https://github.com/modeset/teaspoon), then you can easily get istanbul based coverage reports as well. It's a good way to see which paths your js tests take in a large project and pinpoint untested code.

TheTurkish 12y ago

Why did you name it Istanbul?

ktt 12y ago
> Why the funky name? > Since all the good ones are taken. Comes from the loose association of ideas across coverage, carpet-area coverage, the country that makes good carpets and so on... https://github.com/gotwarlost/istanbul#why-the-funky-name https://github.com/gotwarlost/istanbul#why-the-funky-name
- Tloewald 12y ago
  It made me think of the Neil Simon song.

johnnymonster 12y ago

why is this popping up now? its quite an old project at this point.

gomathinayagam 12y ago

sample LCOA Report links is broken, http://gotwarlost.github.io/istanbul/public/coverage/std-lcov/index.html http://gotwarlost.github.io/istanbul/public/coverage/std-lco...

orkj 12y ago

I use this all the time. This is the command I use for coverage with mocha: ./node_modules/istanbul/lib/cli.js cover -- ./node_modules/mocha/bin/_mocha -R spec Always in my Makefile as make test-cov

jaegerpicker 12y ago

Ah that reminds me I wrote a coverage server for istanbul in node.js. It allows testem to send coverage statics across mutliple tests/runs to reported on. It's part of a whole test running package that I'm working on open sourcing that will allow testem (which is a great test runner if you don't mind running all of your tests in one big session) to run multiple suites of tests. For instance if you have a order app and an client management app and you want separate test runs to avoid any namespace collisions the project allows you to define handlebars based templates to define your suites and run each suite with testem one at a time. Anyway here is a gist of the coverage server if it's useful to anyone: https://gist.github.com/jaegerpicker/95c3900426d55eb9b857 https://gist.github.com/jaegerpicker/95c3900426d55eb9b857

sheetjs 12y ago

I'm a fan of mocha + blanket for coverage: https://github.com/alex-seville/blanket https://github.com/alex-seville/blanket The mocha integration is incredibly easy: mocha --require blanket -R html-cov # for html output

gcb4 12y ago

i have some projects where the meat is in a cross domain connector. no way to test it in units. only functional test in real browsers cut it. otherwise it's just red tape testing. there is zero coverage tool for this case, until browsers wake up and give me a decent Dev api like opera 12 allowed

tekromancr 12y ago

Wasn't this project originally called "Constantinople"?

dragonwriter 12y ago
Surely, the question you mean to ask is if it was originally called "Byzantium".