Yet another JS code coverage tool that computes statement, line, function and branch coverage with module loader hooks to transparently add coverage when running tests. Supports all JS coverage use cases including unit tests, server side functional tests and browser tests. Built for scale.

Related tags

Testing istanbul
Overview

Istanbul - a JS code coverage tool written in JS

Build Status Dependency Status Coverage Status bitHound Score

NPM

Deprecation Notice: this version of istanbul is deprecated, we will not be landing pull requests or releasing new versions. But don't worry, the Istanbul 2.0 API is now available and is being actively developed in the new istanbuljs organization.

New v0.4.0 now has beautiful HTML reports. Props to Tom MacWright @tmcw for a fantastic job!

Features

  • All-javascript instrumentation library that tracks statement, branch, and function coverage.
  • Module loader hooks to instrument code on the fly
  • Command line tools to run node unit tests "with coverage turned on" and no cooperation whatsoever from the test runner
  • Multiple report formats: HTML, LCOV, Cobertura and more.
  • Ability to use as middleware when serving JS files that need to be tested on the browser.
  • Can be used on the command line as well as a library
  • Based on the awesome esprima parser and the equally awesome escodegen code generator
  • Well-tested on node (prev, current and next versions) and the browser (instrumentation library only)

Use cases

Supports the following use cases and more

  • transparent coverage of nodejs unit tests
  • instrumentation/ reporting of files in batch mode for browser tests
  • Server side code coverage for nodejs by embedding it as custom middleware

Getting started

$ npm install -g istanbul

The best way to see it in action is to run node unit tests. Say you have a test script test.js that runs all tests for your node project without coverage.

Simply:

$ cd /path/to/your/source/root
$ istanbul cover test.js

and this should produce a coverage.json, lcov.info and lcov-report/*html under ./coverage

Sample of code coverage reports produced by this tool (for this tool!):

HTML reports

Usage on Windows

Istanbul assumes that the command passed to it is a JS file (e.g. Jasmine, vows etc.), this is however not true on Windows where npm wrap bin files in a .cmd file. Since Istanbul can not parse .cmd files you need to reference the bin file manually.

Here is an example using Jasmine 2:

istanbul cover node_modules\jasmine\bin\jasmine.js

In order to use this cross platform (e.i. Linux, Mac and Windows), you can insert the above line into the script object in your package.json file but with normal slash.

"scripts": {
    "test": "istanbul cover node_modules/jasmine/bin/jasmine.js"
}

Configuring

Drop a .istanbul.yml file at the top of the source tree to configure istanbul. istanbul help config tells you more about the config file format.

The command line

$ istanbul help

gives you detailed help on all commands.

Usage: istanbul help config | <command>

`config` provides help with istanbul configuration

Available commands are:

      check-coverage
              checks overall/per-file coverage against thresholds from coverage
              JSON files. Exits 1 if thresholds are not met, 0 otherwise


      cover   transparently adds coverage information to a node command. Saves
              coverage.json and reports at the end of execution


      help    shows help


      instrument
              instruments a file or a directory tree and writes the
              instrumented code to the desired output location


      report  writes reports for coverage JSON objects produced in a previous
              run


      test    cover a node command only when npm_config_coverage is set. Use in
              an `npm test` script for conditional coverage


Command names can be abbreviated as long as the abbreviation is unambiguous

To get detailed help for a command and what command-line options it supports, run:

istanbul help <command>

(Most of the command line options are not covered in this document.)

The cover command

$ istanbul cover my-test-script.js -- my test args
# note the -- between the command name and the arguments to be passed

The cover command can be used to get a coverage object and reports for any arbitrary node script. By default, coverage information is written under ./coverage - this can be changed using command-line options.

The cover command can also be passed an optional --handle-sigint flag to enable writing reports when a user triggers a manual SIGINT of the process that is being covered. This can be useful when you are generating coverage for a long lived process.

The test command

The test command has almost the same behavior as the cover command, except that it skips coverage unless the npm_config_coverage environment variable is set.

This command is deprecated since the latest versions of npm do not seem to set the npm_config_coverage variable.

The instrument command

Instruments a single JS file or an entire directory tree and produces an output directory tree with instrumented code. This should not be required for running node unit tests but is useful for tests to be run on the browser.

The report command

Writes reports using coverage*.json files as the source of coverage information. Reports are available in multiple formats and can be individually configured using the istanbul config file. See istanbul help report for more details.

The check-coverage command

Checks the coverage of statements, functions, branches, and lines against the provided thresholds. Positive thresholds are taken to be the minimum percentage required and negative numbers are taken to be the number of uncovered entities allowed.

Ignoring code for coverage

  • Skip an if or else path with /* istanbul ignore if */ or /* istanbul ignore else */ respectively.
  • For all other cases, skip the next 'thing' in the source with: /* istanbul ignore next */

See ignoring-code-for-coverage.md for the spec.

API

All the features of istanbul can be accessed as a library.

Instrument code

    var istanbul = require('istanbul');
    var instrumenter = new istanbul.Instrumenter();

    var generatedCode = instrumenter.instrumentSync('function meaningOfLife() { return 42; }',
        'filename.js');

Generate reports given a bunch of coverage JSON objects

    var istanbul = require('istanbul'),
        collector = new istanbul.Collector(),
        reporter = new istanbul.Reporter(),
        sync = false;

    collector.add(obj1);
    collector.add(obj2); //etc.

    reporter.add('text');
    reporter.addAll([ 'lcov', 'clover' ]);
    reporter.write(collector, sync, function () {
        console.log('All reports generated');
    });

For the gory details consult the public API

Multiple Process Usage

Istanbul can be used in a multiple process environment by running each process with Istanbul, writing a unique coverage file for each process, and combining the results when generating reports. The method used to perform this will depend on the process forking API used. For example when using the cluster module you must setup the master to start child processes with Istanbul coverage, disable reporting, and output coverage files that include the PID in the filename. Before each run you may need to clear out the coverage data directory.

    if(cluster.isMaster) {
        // setup cluster if running with istanbul coverage
        if(process.env.running_under_istanbul) {
            // use coverage for forked process
            // disabled reporting and output for child process
            // enable pid in child process coverage filename
            cluster.setupMaster({
                exec: './node_modules/.bin/istanbul',
                args: [
                    'cover', '--report', 'none', '--print', 'none', '--include-pid',
                    process.argv[1], '--'].concat(process.argv.slice(2))
            });
        }
        // ...
        // ... cluster.fork();
        // ...
    } else {
        // ... worker code
    }

Coverage.json

For details on the format of the coverage.json object, see here.

License

istanbul is licensed under the BSD License.

Third-party libraries

The following third-party libraries are used by this module:

Inspired by

  • YUI test coverage - https://github.com/yui/yuitest - the grand-daddy of JS coverage tools. Istanbul has been specifically designed to offer an alternative to this library with an easy migration path.
  • cover: https://github.com/itay/node-cover - the inspiration for the cover command, modeled after the run command in that tool. The coverage methodology used by istanbul is quite different, however

Shout out to

  • mfncooper - for great brainstorming discussions
  • reid, davglass, the YUI dudes, for interesting conversations, encouragement, support and gentle pressure to get it done :)

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...

Comments
  • Add documentation for in browser usage

    Add documentation for in browser usage

    Hi,

    first of all, pretty awesome project :) My problem is, that I´am trying to use it as a middleware to collect some coverage informations from my client side javascript & i´am missing some kind of docs as a starting point how to integrate everything properly.

    I can generate & run instrumented code in the client, but I´am not really sure how to generate a report out of that information. Would be really cool, if one of you guys could add some information on how to do this.

    Regards

    opened by asciidisco 47
  • Missing

    Missing "else" changes branch percentage

    When a script contains an "if" without an "else" the file is flagged for not having covered the "else" that isn't there. This changes the total coverage of the branches incorrectly when the contents of the "if" are fully covered. The lone "if" should be detected correctly.

    opened by mbielski 39
  • All stack traces point to line 9

    All stack traces point to line 9

    Need

    As a developer
    I want meaningful stack traces
    So that I can quickly debug.
    

    Deliverables

    • [ ] Stack traces point to the original line.

    Notes

    Right now, Istanbul seems to put the entire instrumented code on line 9 so every stack trace will point to line 9 which is not very useful. The first 8 lines seem to be setup code for tracking coverage

    A quick win would be to preserve line numbers in the instrumented output. Another way would be to generate source maps.

    Thoughts?

    enhancement 
    opened by NiGhTTraX 36
  • Add some user flexibility for branch coverage stats

    Add some user flexibility for branch coverage stats

    @davglass @reid @mfncooper @sdesai

    Starting this thread to see how we can improve branch coverage in Istanbul.

    Assumption: Default processing is just about ok in the sense of generality and hitting the cases we care about. If not, let me know.

    Based on conversations with some of you here are some desires:

    1. Ability to automatically exclude generally-impossible-to-test-without-a-lot-of-shennanigans branches. The big one here is if (object.hasOwnProperty('foo')) {} style branches where the else path should be considered non-existent and istanbul should probably not even consider this if statement as a branch.
    2. Ability for user to tag certain branches as unimportant/ untestable. Potential implementation is via comments just before the line of code (similar to jslint). Feel free to send thoughts on what this interface should look like.
    3. Ability to specify a reason along with the comment that is somehow shown in the HTML report
    4. Ability (for managers) to ensure that people aren't commenting their way out of their responsibilities (perhaps by having "raw" numbers shown against the "processed" numbers when different?)

    Anyway, ideas welcome. Just keep this issue updated and we can circle back 3-4 weeks from now and decide what needs to be done. I'll also need to do some research on how comments are made available in the parse tree by esprima before we decide the final solution.

    enhancement 
    opened by gotwarlost 33
  • No coverage information was collected, exit without writing coverage information

    No coverage information was collected, exit without writing coverage information

    I can't get any coverage output regardless if I do --report lcov --report html or leave it blank.

    This seems to be a bug with latest versions... it used to work fine.

    I'm using ES6/mocha and having mocha call babel-core/register.

    I've tried every combination of babel-node, ./node_modules/.bin/xyz etc - still no coverage - I've tried lots of options, even --hook-run-in-context which I have no idea what it does, because there's not much documentation for it, or any features. Even the readme of this repo doesn't even talk about available options to pass to --report.

    opened by niftylettuce 29
  • istanbul don't include unrequired JS files in coverage

    istanbul don't include unrequired JS files in coverage

    Hello, In my nodeJS application, i have this package for DAO:

    • api/dao/ClasseA.js
    • api/dao/ClasseB.js

    and this package for unit test with mocha:

    • test/dao/testA.js that require just ClasseA.js.

    I use this command to execute tests for testA.js and generate Cobertura report : istanbul cover --report cobertura mocha test/dao/*.js It's work fine, But the coverage report don't include ClasseB.js in coverage. Any ideas?.

    opened by amoufaddel 28
  • Instrument ES6 generators for coverage

    Instrument ES6 generators for coverage

    When using istanbul on ES6 code it prints a bunch of errors

    Transformation error; return original code
    { [Error: Line 7: Unexpected token *] index: 174, lineNumber: 7, column: 9 }
    Transformation error; return original code
    { [Error: Line 11: Unexpected token *] index: 266, lineNumber: 11, column: 9 }
    Transformation error; return original code
    { [Error: Line 11: Unexpected token *] index: 323, lineNumber: 11, column: 9 }
    Transformation error; return original code
    { [Error: Line 10: Unexpected token *] index: 241, lineNumber: 10, column: 9 }
    Transformation error; return original code
    { [Error: Line 9: Unexpected token *] index: 206, lineNumber: 9, column: 9 }
    Transformation error; return original code
    { [Error: Line 8: Unexpected token *] index: 223, lineNumber: 8, column: 9 }
    Transformation error; return original code
    { [Error: Line 12: Unexpected token *] index: 280, lineNumber: 12, column: 9 }
    Transformation error; return original code
    { [Error: Line 8: Unexpected token *] index: 174, lineNumber: 8, column: 9 }
    Transformation error; return original code
    { [Error: Line 9: Unexpected token *] index: 194, lineNumber: 9, column: 9 }
    Transformation error; return original code
    { [Error: Line 11: Unexpected token *] index: 260, lineNumber: 11, column: 13 }
    Transformation error; return original code
    { [Error: Line 12: Unexpected token *] index: 302, lineNumber: 12, column: 13 }
    

    The result is that every piece of code I have that uses generators is not instrumented.

    opened by Raynos 27
  • Instrument coffeescript

    Instrument coffeescript

    This is my proposal to resolve https://github.com/gotwarlost/istanbul/issues/166. I compiled ibrik's instrumenter.coffee to coffee-instrumenter.js and made the necessary modifications to use it.

    opened by jdfree 26
  • Configuring istanbul with mocha

    Configuring istanbul with mocha

    Istanbul works flawlessly with jasmine-node, using the command: `istanbul cover jasmine-node test'

    Is it possible to use istanbul with mocha, in a similar way. I get the following:

    $ istanbul cover mocha -u exports -R spec
    
    fs.js:684
      return binding.stat(pathModule._makeLong(path));
                     ^
    Error: ENOENT, no such file or directory 'exports.js'
        at Object.fs.statSync (fs.js:684:18)
        at lookupFiles (/usr/local/share/npm/lib/node_modules/mocha/bin/_mocha:390:17)
        at spinner (/usr/local/share/npm/lib/node_modules/mocha/bin/_mocha:268:24)
        at Array.forEach (native)
        at Object.<anonymous> (/usr/local/share/npm/lib/node_modules/mocha/bin/_mocha:267:6)
        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:901:3
    No coverage information was collected, exit without writing coverage information
    

    I tried using https://github.com/arikon/mocha-istanbul as the reporter but got a similar error.

    opened by dankohn 25
  • Nodejs 7.2  async/await

    Nodejs 7.2 async/await

    I'm using NodeJS 7 + gulp-istanbul for my test coverage and i'm getting Unexpected identifier with a async method of a class.

        class SomeClass {
            async someMethod() {
                return await  somePromise();
            }
        }
    

    Is this issue related direct with Istanbul?
    If so, there's some way to support this case?

    opened by gbahamondezc 24
  • error writing html coverage report (missing undefined check?)

    error writing html coverage report (missing undefined check?)

    I bumped into the following error running jest with coverage enabled on a react-native project. Call stack and error is:

    Failed with unexpected error.
    /Users/graeme/src/react-native-stylish/node_modules/jest-cli/src/jest.js:190
          throw error;
                ^
    TypeError: Cannot read property 'text' of undefined
      at /Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:283:53
      at Array.forEach (native)
      at annotateBranches (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:250:30)
      at HtmlReport.Report.mix.writeDetailPage (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:421:9)
      at /Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:484:26
      at SyncFileWriter.extend.writeFile (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/util/file-writer.js:57:9)
      at FileWriter.extend.writeFile (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/util/file-writer.js:147:23)
      at /Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:483:24
      at Array.forEach (native)
      at HtmlReport.Report.mix.writeFiles (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:477:23)
      at /Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:479:22
      at Array.forEach (native)
      at HtmlReport.Report.mix.writeFiles (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:477:23)
      at HtmlReport.Report.mix.writeReport (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/html.js:561:14)
      at LcovReport.Report.mix.writeReport (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/report/lcov.js:55:19)
      at /Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/reporter.js:93:20
      at Array.forEach (native)
      at Object.Reporter.write (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/istanbul/lib/reporter.js:87:30)
      at DefaultTestReporter.IstanbulTestReporter.onRunComplete (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/src/IstanbulTestReporter.js:33:14)
      at /Users/graeme/src/react-native-stylish/node_modules/jest-cli/src/TestRunner.js:457:40
      at tryCatcher (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/bluebird/js/main/util.js:26:23)
      at Promise._settlePromiseFromHandler (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/bluebird/js/main/promise.js:503:31)
      at Promise._settlePromiseAt (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/bluebird/js/main/promise.js:577:18)
      at Promise._settlePromises (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/bluebird/js/main/promise.js:693:14)
      at Async._drainQueue (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/bluebird/js/main/async.js:123:16)
      at Async._drainQueues (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/bluebird/js/main/async.js:133:10)
      at Immediate.Async.drainQueues [as _onImmediate] (/Users/graeme/src/react-native-stylish/node_modules/jest-cli/node_modules/bluebird/js/main/async.js:15:14)
      at processImmediate [as _immediateCallback] (timers.js:371:17)
    

    The problem occurs at https://github.com/gotwarlost/istanbul/blob/master/lib/report/html.js#L283 where it appears that structuredText[startLine] can be null.

    istanbul 2015-08-27 11-17-49

    Adding check to skip lines where structuredText[startLine] was undefined produced what looks like well-formed html output.

    opened by graemej 22
  • docs: fix simple typo, delet -> delete

    docs: fix simple typo, delet -> delete

    There is a small typo in test/run.js.

    Should read delete rather than delet.

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

    opened by timgates42 0
  • Coverage not being collected from file called

    Coverage not being collected from file called "payload.ts"

    This is a very strange one, and I've exhausted known possibilites, at least that I can think of.

    I have the following coverage config for jest:

    // jest.config.js
    
    module.exports = {
      /*[...]*/
      collectCoverage: true,
      collectCoverageFrom: ['<rootDir>/src/**/*.{ts,tsx}'],
      coverageDirectory: '<rootDir>/tests/coverage',
      coveragePathIgnorePatterns: ['/node_modules/', '(.*).d.ts'],
    };
    

    All of my test suites are running correctly, but one file in particular isn't collecting coverage.

    It seems mad, but I feel like it's related to the filename (?!), payload.ts.

    I have three files in my ./src directory:

    • payload.ts
    • utility.ts
    • index.ts

    However, when I run Jest I get the following output:

    $ jest --no-cache
    PASS  tests/payload.test.ts
    PASS  tests/utility.test.ts
    ------------|---------|----------|---------|---------|-------------------
    File        | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
    ------------|---------|----------|---------|---------|-------------------
    All files   |   73.68 |    70.37 |   57.14 |   72.97 |
     index.ts   |       0 |      100 |     100 |       0 | 7-8
     utility.ts |   77.77 |    70.37 |   57.14 |   77.14 | 8-9,53-68
    ------------|---------|----------|---------|---------|-------------------
    
    Test Suites: 2 passed, 2 total
    Tests:       16 passed, 16 total
    Snapshots:   0 total
    Time:        8.816 s
    Ran all test suites.
    ✨  Done in 10.42s.
    

    I've tried removing / re-creating the payload.ts file, thinking it might be filesystem related, but no luck. I've also tried the --no-cache flag that I've seen mentioned elsewhere, but again, no luck.

    If I rename the file to something like payload_s.ts, it works as expected, generating coverage.

    I'll try and put a re-production together sometime soon, but wanted to post this before I forgot / just renamed the file and called it a day.

    Thanks

    opened by jahilldev 0
  • Update handlebars

    Update handlebars

    Hi! 👋 This PR updates the version of handlebars to fix https://github.com/advisories/GHSA-765h-qjxv-5f44 The tests seem to pass, let me know if you need anything else!

    opened by FatemehOstad 0
  • Async package is vulnerable

    Async package is vulnerable

    opened by yar00001 0
  • Istanbul doesn't ignore nested if, when not executed

    Istanbul doesn't ignore nested if, when not executed

    Hello,

    const wrongbranch = () => {
      const a = 2;
      if (a === 1) {
        console.log("test");
        /* istanbul ignore if */
        if (a === 3) {
          console.log("another test")
        }
      }
      return 3;
    }
    

    Saying that second if path is not taken, even though first if was not executed

    However when ignore if is replaced with ignore next it displays properly and calculates branches properly

    const wrongbranch = () => {
      const a = 2;
      if (a === 1) {
        console.log("test");
        /* istanbul ignore next */
        if (a === 3) {
          console.log("another test")
        }
      }
      return 3;
    }
    

    Is this a bug? or it is supposed to be like that?

    Thank you.

    opened by danziamo 0
Owner
Krishnan Anantheswaran
Krishnan Anantheswaran
blanket.js is a simple code coverage library for javascript. Designed to be easy to install and use, for both browser and nodejs.

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

Alex Seville 1.4k Dec 16, 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
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
Generate a big amount of tests

Generate a big amount of tests This repo was created for jest learning purposes. It aims to generate a big amount of tests (based in a template) to ve

Ricardo Montuan 2 Feb 17, 2022
☕️ 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
A Node.js tool to automate end-to-end web testing.

A Node.js tool to automate end-to-end web testing. Write tests in JS or TypeScript, run them and view results. Homepage • Documentation • FAQ • Suppor

Developer Express Inc. 9.5k Jan 9, 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
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
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 mobile web application to check the data on the total covid19 confirmed cases and deaths, check data for all countries with recorded cases.

This is a mobile web application to check the data on the total covid19 confirmed cases and deaths, check data for all countries with recorded cases. It also has a details page to check for the statistics for each region/state if available.

Solomon Hagan 7 Jul 30, 2022
Mirrors the functionality of Apollo client's useQuery hook, but with a "query" being any async function rather than GQL statement.

useAsyncQuery Mirrors the functionality of Apollo client's useQuery hook, but with a "query" being any async function rather than GQL statement. Usage

Alasdair McLeay 7 Nov 16, 2022
This is a Covid Cases Tracker Web app , with Malawi cases as priority .......coontact [email protected] for more info

Getting Started with Create React App This project was bootstrapped with Create React App. for demo visit https://mwcovid-tracker.vercel.app/ Availabl

null 3 May 25, 2022
Yet-Another-Relog-Mod - Just another relog mod. Call it YARM!

Yet Another Relog Mod A relog mod with a name so long, you can just call it YARM for short. Features An aesthetic relog list design that follows my "p

Hail 0 Oct 19, 2022
Jugglr is a tool for managing test data and running tests with a dedicated database running in a Docker container.

Jugglr Jugglr is a tool for managing test data and running tests with a lightweight, dedicated database. Jugglr enables developers, testers, and CI/CD

OSLabs Beta 74 Aug 20, 2022
A large scale simulation which pits millions of space ships against each other in a virtual universe all running directly in SingleStore.

Wasm Space Program In this demo we simulate a fake universe full of thousands of solar systems. In each solar system there are many space ships and en

SingleStore Labs 11 Nov 2, 2022