blanket.js is a simple code coverage library for javascript. Designed to be easy to install and use, for both browser and nodejs.

Related tags

Testing blanket
Overview

Blanket.js

A seamless JavaScript code coverage library.

FYI: Please note that this repo is not actively maintained

If you're looking for a more active project for JavaScript code coverage, I recommend Istanbul.

Project home page
Blanket_js on Twitter for updates and news.

NOTE: All Pull-Requests must be made into the master branch.

Build Status Dependency Status devDependency Status

NOTE: Blanket.js will throw XHR cross domain errors if run with the file:// protocol. See Special Features Guide for more details and workarounds.

Getting Started

Please see the following guides for using Blanket.js:

Browser

Node

Configuration

Philosophy

Blanket.js is a code coverage tool for javascript that aims to be:

  1. Easy to install
  2. Easy to use
  3. Easy to understand

Blanket.js can be run seamlessly or can be customized for your needs.

Mechanism

JavaScript code coverage compliments your existing JavaScript tests by adding code coverage statistics (which lines of your source code are covered by your tests).

Blanket works in a 3 step process:

  1. Loading your source files
  2. Parsing the code using Esprima and node-falafel, and instrumenting the file by adding code tracking lines.
  3. Connecting to hooks in the test runner to output the coverage details after the tests have completed.

Grunt Integration

You've got a few options for using Grunt with Blanket:

grunt-blanket

A Grunt plugin has been created to allow you to use Blanket like a "traditional" code coverage tool (creating instrumented copies of physical files, as opposed to live-instrumenting). The plugin runs as a standlone project and can be found here.

grunt-blanket-qunit

Runs the QUnit-based Blanket report headlessly using PhantomJS. Results are displayed on the console, and the task will cause Grunt to fail if any of your configured coverage thresholds are not met. Minimum code coverage thresholds can be configured per-file, per-module, and globally.

See:

Compatibility and Features List

See the Compatiblity and Feature List including links to working examples.

Roll your own

  1. git clone [email protected]:alex-seville/blanket.git
  2. npm install
  3. Add your custom build details to the grunt.js file under concat
  4. npm run build

A minified and unminfied copy of the source can be created (see the min task).

Development

All development takes place on the master branch
Your pull request must pass all tests (run npm test to be sure) and respect all existing coverage thresholds

Contact

Feel free to add questions to the Issue tracker, or send them to @blanket_js.

Contributors

Thanks to the many people who have contributed to the project.

And thanks also to: RequireJS, Esprima, node-falafel, Mocha, Qunit.

Revision History

Feb 18-15 - 1.2.2 PR's merged, but this project is not actively maintained.

May 1-13 - 1.1.4
Loaded reverting for grunt-blanket, branch tracking reporter fixed, coverage on-the-go (displaying coverage results while a single page is being used).

Apr 28-13 - 1.1.3 YUI support added with custom adapter (and some wrapping code). CompoundJS support appears to be outside the scope of project.

... (see full revision history)

License

Copyright (c) 2012-2013 Alex Seville
Licensed under the MIT license.

Comments
  • Odd behavior when using data-cover-only and Required files

    Odd behavior when using data-cover-only and Required files

    Ok, so I have data-cover-only="//.*/" to get coverage on all files.

    Top-level scripts are: qunit.js, blanket_qunit.js, require.js and all.tests.qunit.js. These four are collected as page scripts initially.

    The require chains are:

    all.tests.qunit --> base.qunit.test.js --> core.js
                    --> ui.qunit.test.js --> screen.js
    

    QUnit then reports "0 tests of 0 passed", and I get a coverage report on: base.qunit.test.js, ui.qunit.test.js, qunit.js, core.js and screen.js.

    Odd behavior:

    • I don't see coverage for all.tests.qunit.js.
    • I don't see coverage on require.js.
    • I don't see coverage on blanket_qunit.js.
    • No tests are run according ot QUnit.

    If I change data-cover-only to something that doesn't include qunit.js, I do get test results according to QUnit, but still no coverage for all.tests.qunit.js.

    opened by provegard 40
  • QUnit requires ?coverage URL param?

    QUnit requires ?coverage URL param?

    I couldn't get Blanket to work with QUnit. My test runner is not different from the ones in Blanket's test directory. When I debugged the code in Chrome, I noticed that QUnit.urlParams.coverage (tested at line 4527 in QUnit-Blanket) was undefined, meaning that the else block that contains coverage:false would run.

    Adding ?coverage to the URL fixed the problem. But I must be making some mistake, right?

    opened by provegard 23
  • JS error prevents Jasmine run and coverage report

    JS error prevents Jasmine run and coverage report

    I'm trying to integrate Blanket in Chutzpah, and one of the test files I'm using for the integration tests contains an error (on purpose):

    var errorThing = {
        thing: ["thing" + someUndefinedVariable]
    };
    

    When I open the test harness that Chutzpah generates in Chrome, the console shows the following:

    Uncaught ReferenceError: someUndefinedVariable is not defined code.js:23
    waiting for blanket... blanket_jasmine.js:4561
    Error parsing instrumented code: ReferenceError: someUndefinedVariable is not defined blanket_jasmine.js:4431
    Uncaught Error: Load timeout for modules: blanket_0,blanket_1
    http://requirejs.org/docs/errors.html#timeout blanket_jasmine.js:4202
    G blanket_jasmine.js:4202
    w blanket_jasmine.js:4209
    (anonymous function)
    

    If I remove Blanket from the test harness, I still get the first ReferenceError, but Jasmine runs all tests as expected.

    I'm using Blanket 1.0.0.

    opened by provegard 22
  • Jasmine executed too early when tests are Required?

    Jasmine executed too early when tests are Required?

    My main test file (all.tests.jasmine.js) doesn't contain any tests, but requires other files that do. I do get a coverage report that contains only all.tests.jasmine.js, but I don't get any test results whatsoever. I added some console output to Blanket, and see the following:

    waiting for blanket... blanket_jasmine.js:4607
    Blanket: loaded file:///C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/all.tests.jasmine.js blanket_jasmine.js:4456
    Blanket: instrumenting file:///C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/all.tests.jasmine.js blanket_jasmine.js:4458
    Blanket: beforeStartTestRunner callback called blanket_jasmine.js:4613
    Blanket: loaded C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/tests/base/base.jasmine.test.js blanket_jasmine.js:4456
    Blanket: instrumenting C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/tests/base/base.jasmine.test.js blanket_jasmine.js:4458
    Blanket: loaded C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/tests/ui/ui.jasmine.test.js blanket_jasmine.js:4456
    Blanket: instrumenting C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/tests/ui/ui.jasmine.test.js blanket_jasmine.js:4458
    Blanket: loaded C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/base/core.js blanket_jasmine.js:4456
    Blanket: instrumenting C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/base/core.js blanket_jasmine.js:4458
    Blanket: loaded C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/ui/screen.js blanket_jasmine.js:4456
    Blanket: instrumenting C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/ui/screen.js blanket_jasmine.js:4458
    

    Note that the beforeStartTestRunner callback is called right after all.tests.jasmine.js is loaded, which is a bit odd. I guess this is what causes my problem - the actual tests (describes and its) are loaded after Jasmine is executed.

    opened by provegard 19
  • Having data-cover-only that matches nothing leads to script error

    Having data-cover-only that matches nothing leads to script error

    If I specify a data-cover-only attribute that matches nothing, e.g. data-cover-only="foo/", I get the following output:

    GET file:///C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/blanket_0.js  blanket_qunit.js:4538
    GET file:///C:/Users/Per/Documents/Projects/Chutzpah/Facts.Integration/bin/Debug/JS/Code/RequireJS/blanket_0.js  blanket_qunit.js:4253
    Uncaught Error: Script error
    http://requirejs.org/docs/errors.html#scripterror blanket_qunit.js:4228
    

    I get no such error when the attribute value is inclusive, so I suppose the script error isn't real. It's hard to debug since Require is minified. Any suggestions?

    opened by provegard 18
  • Invalid string in instrumented code caused by unescaped Windows pathmarks

    Invalid string in instrumented code caused by unescaped Windows pathmarks

    I don't have the time to do a complete PR for this guy but I'll tell you what I do know:

    • I develop on a Windows box. I just cloned a project which was developed likely entirely on Macs.
    • I ran the gruntfile which fired up Mocha to run tests using blanket for code coverage reporting.
    • Blanket barfed with an error something like this:
    [15:55:11] /c/git-repos/project (master)
    $ grunt
    Running "jshint:files" (jshint) task
    >> 24 files lint free.
    
    Running "mochaTest:test" (mochaTest) task
    >> Mocha exploded!
    >> Error: BLANKET-Error parsing instrumented code: Error: BLANKET-Error parsing instrumented code: SyntaxError: c:\git-repos\project\somefile.js:2
    >> if (typeof _$jscoverage['c:\git-repos\project\somefile.js'] === 'u
    >>                         ^^^^^^^^^^^^^^^^^^^^^^^
    >> Unexpected token ILLEGAL
    >>     at c:\git-repos\project\node_modules\blanket\src\index.js:174:35
    >>     at Object.blanket._blanket.instrument (c:\git-repos\project\node_modules\blanket\src\blanket.js:125:17)
    >>     at Object.require.extensions..js (c:\git-repos\project\node_modules\blanket\src\index.js:155:25)
    >>     at Module.load (module.js:355:32)
    >>     at Function.Module._load (module.js:310:12)
    >>     at Module.require (module.js:365:17)
    >>     at require (module.js:384:17)
    >>     at Object.<anonymous> (c:\git-repos\project\test\core\authSpec.js:11:12)
    >>     at Module._compile (module.js:460:26)
    >>     at Module._extensions..js (module.js:478:10)
    Warning: Task "mochaTest:test" failed. Use --force to continue.
    
    Aborted due to warnings.
    [15:57:01] /c/git-repos/project (master)
    $
    

    It looks like the Windows pathmarks are not being escaped. That is, c:\git-repos should be c:\\git-repos, or, since node is pretty smart, it totally works if you use c:/git-repos.

    project/node_modules/blanket/src/index.js looks like this (starting at line 128 for me)

            //instrument js files
            require.extensions['.js'] = function(localModule, filename) {
                var pattern = blanket.options("filter"),
                    reporter_options = blanket.options("reporter_options"),
                    originalFilename = filename,
                    inputFilename = filename;
                filename = blanket.normalizeBackslashes(filename);
    
                //we check the never matches first
    

    If I change it to this (i.e. normalize the input filename), then the error goes away:

            //instrument js files
            require.extensions['.js'] = function(localModule, filename) {
                var pattern = blanket.options("filter"),
                    reporter_options = blanket.options("reporter_options"),
                    originalFilename = filename,
                    inputFilename = blanket.normalizeBackslashes(filename);
                filename = inputFilename;
    
                //we check the never matches first
    
    opened by TomGault 17
  • Stack trace hides certain files

    Stack trace hides certain files

    Thanks again for your work on this project, it's really been a valuable tool for us.

    We're running into an issue where certain stack traces seem to be missing info about key files that were involved. For example, if I disable blanket, and run a test, I see this:

    at Object.CrudUtil.getUserInfo (http://localhost:8083/users/ui/src/query/UserCrudUtil.js:64:45) at command.execute (http://localhost:8083/admin/ui/src/config/commands/LoadUserInfoCommand.js:26:26) at null. (http://localhost:8083/uifw/ui/libs/js/backbone/geppetto.js:150:60) at Backbone.Events.trigger (http://localhost:8083/uifw/ui/libs/js/backbone/backbone.js:163:39) at dispatch (http://localhost:8083/uifw/ui/libs/js/backbone/geppetto.js:125:23) at Marionette.Layout.extend.onRender

    Note the bolded lines. The call to geppetto.js:150 is then triggering a call to LoadUserInfoCommand.js:26.

    If I enable blanket, I can still see the call to geppetto.js at the same line (bolded), but the next line in the call stack is a blanket js line, and the reference to LoadUserInfoCommand is not shown:

    at Object.CrudUtil.getUserInfo (eval at (http://localhost:8083/uifw/ui/libs/js/testing/blanket.js:4772:30), :178:37) at command.execute (eval at (http://localhost:8083/uifw/ui/libs/js/testing/blanket.js:4772:30), :88:18) at null. (http://localhost:8083/uifw/ui/libs/js/backbone/geppetto.js:150:60) at Backbone.Events.trigger (http://localhost:8083/uifw/ui/libs/js/backbone/backbone.js:163:39) at dispatch (http://localhost:8083/uifw/ui/libs/js/backbone/geppetto.js:125:23) at Marionette.Layout.extend.onRender (eval at (http://localhost:8083/uifw/ui/libs/js/testing/blanket.js:4772:30), :151:14)

    Just wondering if there is a way to avoid this. If there is not a quick fix, is there a way to disable blanketJS without commenting out the script reference to it? Simply leaving "Enable Coverage" unchecked still seems to result in the code being instrumented, since still see the modified stack trace.

    Thanks!

    opened by geekdave 17
  • Reporter API

    Reporter API

    For the browser:

    I'll still include the default reporter (even though it's not reporting accurately right now) but create a mechanism for specifying alternative reporters. I think maybe using another data attribute on the blanket script reference, like:

    <Script src="blanket.js" data-cover-reporter="mocha-reporter.js"></script>

    which would load the mocha-reporter.js file for use in reporting the results in browser (for mocha in browser tests).

    To create your own API, I'll publish some documentation. Basically the reporter should export a function (not unlike mocha reporters in node) and it should expect a coverage variable from blanket.

    That coverage variable is of this format:

    { 
        filenamekey: {
                [null,0,1,0,1,1,1], //line coverage
                ['this','is','the','source code;'],
              }
      , // you can also include test data
    }
    

    I'll create a simple example in the coming days, that way people can contribute their own reporters. The only thing standing in the way of supporting the various different test runners is the command to stop/start tests and the reporting.

    low priority compatibility/support 
    opened by alex-seville 17
  • data-cover attribute on source file is resulting in global failure

    data-cover attribute on source file is resulting in global failure

    hi,

    I set the data-cover attribute on the src script file as below.

    and it is giving the following error.

    too much recursion Source:

    http://localhost:8001/test/js/blanket.min.js:1

    opened by ramkms6666 15
  • Exit instrumentation when user redefines

    Exit instrumentation when user redefines "window"

    The redefine of “window” in the middle of the function breaks code coverage because it depends on “window”. The reason why it breaks it is because JavaScript moves all variables to the top of the function. When adding instrumentation, var'ing “window” will cause it to be null from the start of the function that window._$blanket depends on.

    For example this will fail:

    !function (CustomWindow) {
        CustomWindow.flags = (function () {
          return {
            w: _w
         };
       })();
       var window = CustomWindow.flags.w; // Not valid code for instrumentation.
    }
    ((window.CustomWindow = window.CustomWindow || {}));
    

    It fails because JavaScript moves all variable declarations to the beginning of the function, causing this instrumentation code to fail:

    window._$blanket= {};
    window._$blanket["filea"] = [];
    !function (CustomWindow) {
        var window;
        window._$blanket["filea"][0] += 1; // Fails
        CustomWindow.flags = (function () {
          window._$blanket["filea"][0] += 2;
          return {
            w: _w
         };
       })();
       window._$blanket["filea"][0] += 3;
       window = CustomWindow.flags.w;
       window._$blanket["filea"][0] += 4;
    }
    window._$blanket["filea"][0] += 5;
    ((window.CustomWindow = window.CustomWindow || {}));
    window._$blanket["filea"][0] += 6;
    

    The error the user just sees is from:

    TypeError: Cannot call method _$blanket of null
    

    Which pretty much can mean a lot of things in blanket, but if the user redefines "window" we should inform the user they are doing something wrong and throw and error back.

    opened by mohamedmansour 15
  • Using async XHR to load loader and adapter files

    Using async XHR to load loader and adapter files

    phantomjs (latest) doesn't support sync XHR. Is it strictly necessary for _loadFile to use sync XHR to load the loaders and adapters? It should be fairly straightforward to do async XHR instead. Thoughts?

    opened by ashwinr 15
  • docs: Fix a few typos

    docs: Fix a few typos

    There are small typos in:

    • test/backbone-koans/js/ext/backbone.js
    • test/backbone-koans/js/ext/jquery.js
    • test/backbone-koans/js/ext/sinon-1.3.1.js
    • test/commonjs/commonjs_bundle.js
    • test/jquery-usage/js/ext/backbone.js
    • test/jquery-usage/js/ext/jquery.js
    • test/jquery-usage/js/ext/sinon-1.3.1.js
    • test/usage/backbone.js

    Fixes:

    • Should read preferred rather than prefered.
    • Should read synchronously rather than synchronuously.
    • Should read properties rather than proeprties.
    • Should read profiler rather than prefiler.
    • Should read overridden rather than overriden.
    • Should read occasionally rather than occationaly.

    Semi-automated pull request generated by https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md

    opened by timgates42 0
  • Deprecate this?

    Deprecate this?

    FYI: Please note that this repo is not actively maintained If you're looking for a more active project for JavaScript code coverage, I recommend Istanbul.

    This haven't been updated in years. Deprecate the npm package and archive this repo?

    opened by jimmywarting 0
  • Running Jasmine Code Coverage using command Line

    Running Jasmine Code Coverage using command Line

    Blanket JS with Mocha runs with a simple command:

    mocha --require blanket

    But how do I run Jasmine based test cases with a command?

    The only example I came across is a browser based one: https://github.com/alex-seville/blanket/tree/master/test/jasmine

    opened by parth-intel 0
  • Instrumentation affects test results.

    Instrumentation affects test results.

    Hi, first of all thank you for blanket.js. I'm using it since some time and it works brilliant for me. Nevertheless, I've just faced an issue.

    I have the following test:

    image

    operating on such a DOM:

    image

    I'm using Chutzpah (v 4.2.4) test runner from @mmanela to run the tests.

    When executing it without the coverage support, the test passes. When blanket coverage is on, the test fails:

    image

    Could you help me to determine what can be the source of the problem? Thank you very much in advance.

    I'm attaching the repro.zip. This is an archive containing tiny, yet complete, sample which allows you to reproduce the error shown above - execute test.ps1 script to see it.

    opened by jwaliszko 0
  • make a new release on the github?

    make a new release on the github?

    I use bower to pull this in and on the website it says version 1.2.2 but here it says 1.1.7 I am having no problems but i was wondering if there could be a new release on the github when deemed needed. Thanks

    opened by dtracers 0
Owner
Alex Seville
VP of Engineering at Flickr.
Alex Seville
JSCover is a JavaScript Code Coverage Tool that measures line, branch and function coverage

JSCover - A JavaScript code coverage measurement tool. JSCover is an easy-to-use JavaScript code coverage measuring tool. It is an enhanced version of

null 392 Nov 20, 2022
🔮 An easy-to-use JavaScript unit testing framework.

QUnit - A JavaScript Unit Testing Framework. QUnit is a powerful, easy-to-use, JavaScript unit testing framework. It's used by the jQuery project to t

QUnit 4k Jan 2, 2023
☕️ simple, flexible, fun javascript test framework for node.js & the browser

☕️ Simple, flexible, fun JavaScript test framework for Node.js & The Browser ☕️ Links Documentation Release Notes / History / Changes Code of Conduct

Mocha 21.8k Dec 30, 2022
Demo Selenium JavaScript E2E tests (end-to-end web browser automation tests)

Demo Selenium JavaScript E2E tests (end-to-end web browser automation tests)

Joel Parker Henderson 1 Oct 9, 2021
A single tab web browser built with puppeteer. Also, no client-side JS. Viewport is streamed with MJPEG. For realz.

:tophat: A single tab web browser built with puppeteer. Also, no client-side JS. Viewport is streamed with MJPEG. For realz.

Cris 23 Dec 23, 2022
Simple JavaScript testing framework for browsers and node.js

A JavaScript Testing Framework Jasmine is a Behavior Driven Development testing framework for JavaScript. It does not rely on browsers, DOM, or any Ja

Jasmine 15.5k Jan 2, 2023
Simple interactive HTTP response mocker, useful for testing API callouts.

Simple interactive HTTP response mocker, useful for testing API callouts.

null 1 Jul 1, 2022
Delightful JavaScript Testing.

?? Delightful JavaScript Testing ????‍?? Developer Ready: A comprehensive JavaScript testing solution. Works out of the box for most JavaScript projec

Facebook 41k Jan 4, 2023
Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.

?? Playwright Documentation | API reference Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit w

Microsoft 46.3k Jan 9, 2023
Test runner based on Tape and Browserify

prova Node & Browser Test runner based on Tape and Browserify. Screencasts: node.gif, browser.gif, both.gif, headless browser Slides: slides.com/azer/

Azer Koçulu 335 Oct 28, 2022
tap-producing test harness for node and browsers

tape tap-producing test harness for node and browsers example var test = require('tape'); test('timing test', function (t) { t.plan(2); t.eq

James Halliday 5.7k Dec 18, 2022
Cypress Playback is a plugin and a set of commands that allows Cypress to automatically record responses to network requests made during a test run.

Cypress Playback ?? Automatically record and playback HTTP requests made in Cypress tests. Cypress Playback is a plugin and a set of commands that all

O’Reilly Media, Inc. 5 Dec 16, 2022
JSCover is a JavaScript Code Coverage Tool that measures line, branch and function coverage

JSCover - A JavaScript code coverage measurement tool. JSCover is an easy-to-use JavaScript code coverage measuring tool. It is an enhanced version of

null 392 Nov 20, 2022
A quick and easy to use security reconnaissance webapp tool, does OSINT, analysis and red-teaming in both passive and active mode. Written in nodeJS and Electron.

ᵔᴥᵔ RedJoust A quick and easy to use security reconnaissance webapp tool, does OSINT, analysis and red-teaming in both passive and active mode. Writte

Dave 17 Oct 31, 2022
👋 Canyon is a JavaScript code coverage platform

Canyon Welcome to the Canyon codebase, we are thrilled to have you here! What is Canyon? Canyon is a JavaScript code coverage platform. Canyon can rea

Canyon 99 Oct 6, 2022
Easiest 1-click way to install and use Stable Diffusion on your own computer. Provides a browser UI for generating images from text prompts and images. Just enter your text prompt, and see the generated image.

Stable Diffusion UI Easiest way to install and use Stable Diffusion on your own computer. No dependencies or technical knowledge required. 1-click ins

null 3.5k Dec 30, 2022
ENS Avatar resolver library for both nodejs and browser.

ens-avatar Avatar resolver library for both nodejs and browser. Getting started Prerequisites Have your web3 provider ready (web3.js, ethers.js) [Only

Ethereum Name Service (ENS) 27 Dec 30, 2022
Grupprojekt för kurserna 'Javascript med Ramverk' och 'Agil Utveckling'

JavaScript-med-Ramverk-Laboration-3 Grupprojektet för kurserna Javascript med Ramverk och Agil Utveckling. Utvecklingsguide För information om hur utv

Svante Jonsson IT-Högskolan 3 May 18, 2022
Hemsida för personer i Sverige som kan och vill erbjuda boende till människor på flykt

Getting Started with Create React App This project was bootstrapped with Create React App. Available Scripts In the project directory, you can run: np

null 4 May 3, 2022