{ "_args": [ [ { "raw": "testem@^1.18.0", "scope": null, "escapedName": "testem", "name": "testem", "rawSpec": "^1.18.0", "spec": ">=1.18.0 <2.0.0", "type": "range" }, "/home/travis/build/lukesargeant/ember-sparkline/node_modules/ember-cli" ] ], "_from": "testem@>=1.18.0 <2.0.0", "_id": "testem@1.18.4", "_inCache": true, "_location": "/testem", "_nodeVersion": "6.11.0", "_npmOperationalInternal": { "host": "s3://npm-registry-packages", "tmp": "tmp/testem-1.18.4.tgz_1503041225041_0.8017994367983192" }, "_npmUser": { "name": "johanneswuerbach", "email": "johannes.wuerbach@googlemail.com" }, "_npmVersion": "3.10.10", "_phantomChildren": {}, "_requested": { "raw": "testem@^1.18.0", "scope": null, "escapedName": "testem", "name": "testem", "rawSpec": "^1.18.0", "spec": ">=1.18.0 <2.0.0", "type": "range" }, "_requiredBy": [ "/ember-cli" ], "_resolved": "https://registry.npmjs.org/testem/-/testem-1.18.4.tgz", "_shasum": "e45fed922bec2f54a616c43f11922598ac97eb41", "_shrinkwrap": null, "_spec": "testem@^1.18.0", "_where": "/home/travis/build/lukesargeant/ember-sparkline/node_modules/ember-cli", "author": { "name": "Toby Ho", "email": "airportyh@gmail.com" }, "bin": { "testem": "./testem.js" }, "bugs": { "url": "http://github.com/testem/testem/issues" }, "dependencies": { "backbone": "^1.1.2", "bluebird": "^3.4.6", "charm": "^1.0.0", "commander": "^2.6.0", "consolidate": "^0.14.0", "cross-spawn": "^5.1.0", "express": "^4.10.7", "fireworm": "^0.7.0", "glob": "^7.0.4", "http-proxy": "^1.13.1", "js-yaml": "^3.2.5", "lodash.assignin": "^4.1.0", "lodash.clonedeep": "^4.4.1", "lodash.find": "^4.5.1", "lodash.uniqby": "^4.7.0", "mkdirp": "^0.5.1", "mustache": "^2.2.1", "node-notifier": "^5.0.1", "npmlog": "^4.0.0", "printf": "^0.2.3", "rimraf": "^2.4.4", "socket.io": "1.6.0", "spawn-args": "^0.2.0", "styled_string": "0.0.1", "tap-parser": "^5.1.0", "xmldom": "^0.1.19" }, "description": "Test'em 'scripts! Javascript Unit testing made easy.", "devDependencies": { "bluebird-retry": "^0.9.0", "browserify": "^13.0.0", "chai": "^4.0.2", "chai-files": "^1.2.0", "chai-shallow-deep-equal": "^1.4.4", "cheerio": "^0.22.0", "dirty-chai": "^2.0.0", "eslint": "^4.1.0", "eslint-plugin-chai-expect": "^1.1.1", "eslint-plugin-mocha": "^4.3.0", "mocha": "^3.0.0", "request": "^2.51.0", "saucie": "^3.0.1", "shelljs": "^0.7.0", "sinon": "^2.3.2", "sinon-chai": "^2.8.0", "tape": "^4.0.0", "tmp": "0.0.33" }, "directories": {}, "dist": { "shasum": "e45fed922bec2f54a616c43f11922598ac97eb41", "tarball": "https://registry.npmjs.org/testem/-/testem-1.18.4.tgz" }, "engines": [ "node >= 0.8.0" ], "files": [ "lib", "public", "README.md", "testem.js", "assets", "package.json", "views" ], "gitHead": "523b3312609140801fd7f00c9fdd81d7fd22ba28", "homepage": "https://github.com/testem/testem#readme", "keywords": [ "javascript", "testing", "unittest", "browser" ], "license": "MIT", "main": "./lib/api.js", "maintainers": [ { "name": "johanneswuerbach", "email": "johannes.wuerbach@googlemail.com" }, { "name": "airportyh", "email": "airportyh@gmail.com" } ], "name": "testem", "optionalDependencies": {}, "readme": "Got Scripts? Test’em!\n=================\n\n[![Build Status](https://travis-ci.org/testem/testem.svg?branch=master)](https://travis-ci.org/testem/testem) [![Dependency Status](https://david-dm.org/testem/testem.svg)](https://david-dm.org/testem/testem) [![npm version](https://badge.fury.io/js/testem.svg)](http://badge.fury.io/js/testem) [![Windows build status](https://ci.appveyor.com/api/projects/status/l948rc4rv391ayge/branch/master?svg=true)](https://ci.appveyor.com/project/johanneswuerbach/testem/branch/master)\n\nUnit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually *want* to write tests.\n\nFeatures\n--------\n\n* Test-framework agnostic. Support for\n - [Jasmine](http://jasmine.github.io/)\n - [QUnit](http://qunitjs.com/)\n - [Mocha](http://mochajs.org/)\n - [Buster.js](http://docs.busterjs.org/)\n - Others, through custom test framework adapters.\n* Run tests in all major browsers as well as [Node](http://nodejs.org) and [PhantomJS](http://phantomjs.org/)\n* Two distinct use-cases:\n - Test-Driven-Development(TDD) — designed to streamline the TDD workflow\n - Continuous Integration(CI) — designed to work well with popular CI servers like Jenkins or Teamcity\n* Cross-platform support\n - OS X\n - Windows\n - Linux\n* Preprocessor support\n - CoffeeScript\n - Browserify\n - JSHint/JSLint\n - everything else\n\nScreencasts\n-----------\n\n* Watch this **[introductory screencast (11:39)](http://www.youtube.com/watch?v=-1mjv4yk5JM)** to see it in action! This one demonstrates the TDD workflow.\n* [Launchers (12:10)](http://www.youtube.com/watch?v=Up0lVjWk9Rk) — more detail about launchers: how to specify what to auto-launch and how to configure one yourself to run tests in **Node**.\n* [Continuous Integration (CI) Mode (4:24)](http://www.youtube.com/watch?v=Js16Cj80HKY) — details about how CI mode works.\n* [Making JavaScript Testing Fun With Testem (22:53)](http://net.tutsplus.com/tutorials/javascript-ajax/make-javascript-testing-fun-with-testem/) — a thorough screencast by NetTuts+'s Jeffery Way covering the basics, Jasmine, Mocha/Chai, CoffeeScript and more!\n\nInstallation\n------------\nYou need [Node](http://nodejs.org/) version 0.10+ or iojs installed on your system. Node is extremely easy to install and has a small footprint, and is really awesome otherwise too, so [just do it](http://nodejs.org/).\n\nOnce you have Node installed:\n\n npm install testem -g\n\nThis will install the `testem` executable globally on your system.\n\nUsage\n-----\n\nAs stated before, Testem supports two use cases: test-driven-development and continuous integration. Let's go over each one.\n\nDevelopment Mode\n----------------\n\nThe simplest way to use Testem, in the TDD spirit, is to start in an empty directory and run the command\n\n testem\n\nYou will see a terminal-based interface which looks like this\n\n![Initial interface](https://github.com/testem/testem/raw/master/images/initial.png)\n\nNow open your browser and go to the specified URL. You should now see\n\n![Zero of zero](https://github.com/testem/testem/raw/master/images/zeros.png)\n\nWe see 0/0 for tests because at this point we haven't written any code. As we write them, Testem will pick up any `.js` files\nthat were added, include them, and if there are tests, run them automatically. So let's first write `hello_spec.js` in the spirit of \"test first\" (written in Jasmine)\n\n```javascript\ndescribe('hello', function(){\n it('should say hello', function(){\n expect(hello()).toBe('hello world');\n });\n});\n```\nSave that file and now you should see\n\n![Red](https://github.com/testem/testem/raw/master/images/red.png)\n\nTestem should automatically pick up the new files you've added and also any changes that you make to them and rerun the tests. The test fails as we'd expect. Now we implement the spec like so in `hello.js`\n\n```javascript\nfunction hello(){\n return \"hello world\";\n}\n```\n\nSo you should now see\n\n![Green](https://github.com/testem/testem/raw/master/images/green.png)\n\n### Using the Text User Interface\n\nIn development mode, Testem has a text-based graphical user interface which uses keyboard-based controls. Here is a list of the control keys\n\n* ENTER : Run the tests\n* q : Quit\n* ← LEFT ARROW : Move to the next browser tab on the left\n* → RIGHT ARROW : Move to the next browser tab on the right\n* TAB : switch the target text panel between the top and bottom halves of the split panel (if a split is present)\n* ↑ UP ARROW : scroll up in the target text panel\n* ↓ DOWN ARROW : scroll down in the target text panel\n* SPACE : page down in the target text panel\n* b : page up in the target text panel\n* d : half a page down target text panel\n* u : half a page up target text panel\n\n### Command line options\n\nTo see all command line options\n\n testem --help\n\nContinuous Integration Mode\n---------------------------\n\nTo use Testem for continuous integration\n\n testem ci\n\nIn CI mode, Testem runs your tests on all the browsers that are available on the system one after another.\n\nYou can run multiple browsers in parallel in CI mode by specifying the `--parallel` (or `-P`) option to be the number of concurrent running browsers.\n\n testem ci -P 5 # run 5 browser in parallel\n\nTo find out what browsers are currently available - those that Testem knows about and can make use of\n\n testem launchers\n\nWill print them out. The output might look like\n\n $ testem launchers\n Browsers available on this system:\n IE7\n IE8\n IE9\n Chrome\n Firefox\n Safari\n Safari Technology Preview\n Opera\n PhantomJS\n\nDid you notice that this system has IE versions 7-9? Yes, actually it has only IE9 installed, but Testem uses IE's compatibility mode feature to emulate IE 7 and 8.\n\nWhen you run `testem ci` to run tests, it outputs the results in the [TAP](http://testanything.org/) format by default, which looks like\n\n ok 1 Chrome 16.0 - hello should say hello.\n\n 1..1\n # tests 1\n # pass 1\n\n # ok\n\nTAP is a human-readable and language-agnostic test result format. TAP plugins exist for popular CI servers\n\n* [Jenkins TAP plugin](https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin) - I've added [detailed instructions](https://github.com/testem/testem/blob/master/docs/use_with_jenkins.md) for setup with Jenkins.\n* [TeamCity TAP plugin](https://github.com/pavelsher/teamcity-tap-parser)\n\n## TAP Options\n\nBy default, the TAP reporter outputs logs from all tests that emit logs. You can disable this behavior and only emit logs for failed tests using:\n\n```json\n{\n \"tap_quiet_logs\": true\n}\n```\n\n## Other Test Reporters\n\nTestem has other test reporters besides TAP: `dot`, `xunit` and `teamcity`. You can use the `-R` to specify them\n\n testem ci -R dot\n\nYou can also [add your own reporter](docs/custom_reporter.md).\n\n### Example xunit reporter output\n\nNote that the real output is not pretty printed.\n```xml\n\n \n \n \n \n \n \n \n \n\n```\n\n### Example teamcity reporter output\n\n ##teamcity[testStarted name='PhantomJS 1.9 - hello should say hello']\n ##teamcity[testFinished name='PhantomJS 1.9 - hello should say hello']\n ##teamcity[testStarted name='PhantomJS 1.9 - hello should say hello to person']\n ##teamcity[testFinished name='PhantomJS 1.9 - hello should say hello to person']\n ##teamcity[testStarted name='PhantomJS 1.9 - goodbye should say goodbye']\n ##teamcity[testFailed name='PhantomJS 1.9 - goodbye should say goodbye' message='expected |'hello world|' to equal |'goodbye world|'' details='AssertionError: expected |'hello world|' to equal |'goodbye world|'|n at http://localhost:7357/testem/chai.js:873|n at assertEqual (http://localhost:7357/testem/chai.js:1386)|n at http://localhost:7357/testem/chai.js:3627|n at http://localhost:7357/hello_spec.js:14|n at callFn (http://localhost:7357/testem/mocha.js:4338)|n at http://localhost:7357/testem/mocha.js:4331|n at http://localhost:7357/testem/mocha.js:4728|n at http://localhost:7357/testem/mocha.js:4819|n at next (http://localhost:7357/testem/mocha.js:4653)|n at http://localhost:7357/testem/mocha.js:4663|n at next (http://localhost:7357/testem/mocha.js:4601)|n at http://localhost:7357/testem/mocha.js:4630|n at timeslice (http://localhost:7357/testem/mocha.js:5761)']\n ##teamcity[testFinished name='PhantomJS 1.9 - goodbye should say goodbye']\n\n ##teamcity[testSuiteFinished name='mocha.suite' duration='11091']\n\n### Command line options\n\nTo see all command line options for CI\n\n testem ci --help\n\nConfiguration File\n------------------\n\nFor the simplest JavaScript projects, the TDD workflow described above will work fine. There are times when you want\nto structure your source files into separate directories, or want to have finer control over what files to include.\nThis calls for the `testem.json` configuration file (you can also alternatively use the YAML format with a `testem.yml` file). It looks like\n\n```json\n{\n \"framework\": \"jasmine\",\n \"src_files\": [\n \"hello.js\",\n \"hello_spec.js\"\n ]\n}\n```\n\nThe `src_files` can also be unix glob patterns.\n\n```json\n{\n \"src_files\": [\n \"js/**/*.js\",\n \"spec/**/*.js\"\n ]\n}\n```\n\nYou can also ignore certain files using `src_files_ignore`.\n***Update: I've removed the ability to use a space-separated list of globs as a string in the `src_files` property because it disallowed matching files or directories with spaces in them.***\n\n```json\n{\n \"src_files\": [\n \"js/**/*.js\",\n \"spec/**/*.js\"\n ],\n \"src_files_ignore\": \"js/toxic/*.js\"\n}\n```\n\nRead [more details](docs/config_file.md) about the config options.\n\nCustom Test Pages\n-----------------\n\nYou can also use a custom page for testing. To do this, first you need to specify `test_page` to point to your test page in the config file (`framework` and `src_files` are irrelevant in this case)\n\n```json\n{\n \"test_page\": \"tests.html\",\n \"launch_in_dev\": [\n \"Chrome\"\n ]\n}\n```\n\nNext, the test page you use needs to have the adapter code installed on them, as specified in the next section.\n\n### Include Snippet\n\nInclude this snippet directly after your `jasmine.js`, `qunit.js` or `mocha.js` or `buster.js` scripts to enable *Testem* with your test page.\n\n```html\n\n```\n\nOr if you are using require.js or another loader, just make sure you load `/testem.js` as the next script after the test framework.\n\n'/testem.js' here is dynamically generated to be used client-side and it should not be confused with server-side 'testem.js'.\n\n### Dynamic Substitution\n\nTo enable dynamic substitutions within the Javascript files in your custom test page, you must\n\n1. name your test page using `.mustache` as the extension\n2. use `{{#serve_files}}` to loop over the set of Javascript files to be served, and then reference its `src` property to access their path (or `{{#css_files}}` for stylesheets)\n\nExample:\n\n {{#serve_files}}\n \n {{/serve_files}}\n\n {{#css_files}}\n \n {{/css_files}}\n\n### Multiple Test Pages\n\nYou can also specify multiple test pages to run by passing an array to the `test_page` option.\n\n```json\n{\n \"test_page\": [\n \"unit-tests.html\",\n \"integration-tests.html\"\n ]\n}\n```\n\nThis will cause Testem to run each test page in a separate launcher instance for each launcher you are using. This means that if you define 2 test pages and are using 3 launchers you will get 6 unique runs (2 per launcher).\n\nLaunchers\n---------\n\nTestem has the ability to automatically launch browsers or processes for you. To see the list of launchers Testem knows about, you can use the command\n\n testem launchers\n\nThis will display something like the following\n\n Have 5 launchers available; auto-launch info displayed on the right.\n\n Launcher Type CI Dev\n ------------ ------------ -- ---\n Chrome browser ✔\n Firefox browser ✔\n Safari browser ✔\n Opera browser ✔\n Mocha process(TAP) ✔\n\nThis displays the current list of launchers that are available. Launchers can launch either a browser or a custom process — as shown in the \"Type\" column. Custom launchers can be defined to launch custom processes. The \"CI\" column indicates the launchers which will be automatically launched in CI-mode. Similarly, the \"Dev\" column lists those that will automatically launch in dev-mode.\n\nCustomizing Browser Arguments\n-----------------------------\n\nTestem passes its own list of arguments to some of the browsers it launches. You can add your own custom arguments to these lists by including the `browser_args` option in your Testem configuration. For example:\n\n```javascript\n\"browser_args\": {\n \"Chrome\": [\n \"--auto-open-devtools-for-tabs\"\n ]\n}\n```\n\nYou can supply arguments to any number of browsers Testem has available by using the launcher name as a key in `browser_args`. Values may be an array of string arguments, a single string, or an object specifying `args` and a `mode` to apply them to.\n\nRead [more details](docs/browser_args.md) about the browser argument options.\n\nRunning Tests in Node and Custom Process Launchers\n--------------------------------------------------\n\nTo run tests in Node you need to create a custom launcher which launches a process which will run your tests. This is nice because it means you can use any test framework - or lack thereof. For example, to make a launcher that runs mocha tests, you would write the following in the config file `testem.json`\n\n```javascript\n\"launchers\": {\n \"Mocha\": {\n \"command\": \"mocha tests/*_tests.js\"\n }\n}\n```\n\nWhen you run `testem`, it will auto-launch the mocha process based on the specified command every time the tests are run. It will display the stdout and well as the stderr of the process inside of the \"Mocha\" tab in the UI. It will base the pass/fail status on the exit code of the process. In fact, because Testem can launch any arbitrary process for you, you could very well be using it to run programs in other languages.\n\nProcesses with TAP Output\n-------------------------\n\nIf your process outputs test results in [TAP](http://en.wikipedia.org/wiki/Test_Anything_Protocol) format, you can tell that to testem via the `protocol` property. For example\n\n```javascript\n\"launchers\": {\n \"Mocha\": {\n \"command\": \"mocha tests/*_tests.js -R tap\",\n \"protocol\": \"tap\"\n }\n}\n```\n\nWhen this is done, Testem will read in the process's stdout and parse it as TAP, and then display the test results in Testem's normal format. It will also hide the process's stdout output from the console log panel, although it will still display the stderr.\n\nPhantomJS\n---------\n\nPhantomJS is a Webkit-based headless browser. It's fast and it's awesome! Testem will pick it up if you have [PhantomJS](http://www.phantomjs.org/) installed in your system and the `phantomjs` executable is in your path. Run\n\n testem launchers\n\nAnd verify that it's in the list.\n\nIf you want to debug tests in PhantomJS, include the `phantomjs_debug_port` option in your testem configuration, referencing an available port number. Once testem has started PhantomJS, navigate (with a traditional browser) to http://localhost: and attach to one of PhantomJS's browser tabs (probably the second one in the list). `debugger` statements will now break in the debugging console.\n\nIf you want to use any of the [PhantomJS command line options](http://phantomjs.org/api/command-line.html), include the `phantomjs_args` option in your testem configuration. For example:\n\n```javascript\n\"phantomjs_args\": [\n \"--ignore-ssl-errors=true\"\n]\n```\n\nYou can also customize the phantomjs launcher file by specifying the `phantomjs_launch_script` option.\nIn this launcher you can change options like the `viewPortSize`. See `assets/phantom.js` for the default launcher.\n\nPreprocessors (CoffeeScript, LESS, Sass, Browserify, etc)\n---------------------------------------------------------\n\nIf you need to run a preprocessor (or indeed any shell command before the start of the tests) use the `before_tests` option, such as\n\n \"before_tests\": \"coffee -c *.coffee\"\n\nAnd Testem will run it before each test run. For file watching, you may still use the `src_files` option\n\n```javascript\n\"src_files\": [\n \"*.coffee\"\n]\n```\n\nSince you want to be serving the `.js` files that are generated and not the `.coffee` files, you want to specify the `serve_files` option to tell it that\n\n```javascript\n\"serve_files\": [\n \"*.js\"\n]\n```\n\nTestem will throw up a big ol' error dialog if the preprocessor command exits with an error code, so code checkers like jshint can be used here as well.\n\nIf you need to run a command after your tests have completed (such as removing compiled `.js` files), use the `after_tests` option.\n\n```javascript\n\"after_tests\": \"rm *.js\"\n```\n\nIf you would prefer simply to clean up when Testem exits, you can use the `on_exit` option.\n\nRunning browser code after tests complete\n-------------\nIt is possible to send coverage reports or run other JavaScript in the browser by using the `afterTests` method.\n\n```javascript\nTestem.afterTests(\n function(config, data, callback) {\n var coverage = window.__coverage__;\n var postBody = JSON.stringify(coverage);\n if (postBody) {\n var xhr = new XMLHttpRequest();\n xhr.onreadystatechange = function() {\n if (xhr.readyState === 4) {\n callback();\n }\n };\n xhr.open('POST', 'http://localhost:7358/', true);\n xhr.send(postBody);\n }\n});\n```\n\n\nCustom Routes\n-------------\n\nSometimes you may want to re-map a URL to a different directory on the file system. Maybe you have the following file structure:\n\n + src\n + hello.js\n + tests.js\n + css\n + styles.css\n + public\n + tests.html\n\nLet's say you want to serve `tests.html` at the top level url `/tests.html`, all the Javascripts under `/js` and all the css under `/css`. You can use the \"routes\" option to do that\n\n```javascript\n\"routes\": {\n \"/tests.html\": \"public/tests.html\",\n \"/js\": \"src\",\n \"/css\": \"css\"\n}\n```\n\nDIY: Use Any Test Framework\n---------------------------\n\nIf you want to use Testem with a test framework that's not supported out of the box, you can write your own custom test framework adapter. See [customAdapter.js](https://github.com/testem/testem/blob/master/examples/custom_adapter/customAdapter.js) for an example of how to write a custom adapter.\n\nThen, to use it, in your config file simply set\n\n```javascript\n\"framework\": \"custom\"\n```\n\nAnd then make sure you include the adapter code in your test suite and you are ready to go. See here for the [full example](https://github.com/testem/testem/tree/master/examples/custom_adapter).\n\nNative notifications\n--------------------------------\n\nIf you'd prefer not to be looking at the terminal while developing, you can enable native notifications (e.g. notification center, growl) using the `-g` option.\n\nAPI Proxy\n--------------------------------\n\nThe proxy option allows you to transparently forward HTTP requests to an external endpoint.\n\nSimply add a `proxies` section to the `testem.json` configuration file.\n\n```json\n{\n \"proxies\": {\n \"/api\": {\n \"target\": \"http://localhost:4200\",\n \"onlyContentTypes\": [\"xml\", \"json\"]\n },\n \"/xmlapi\": {\n \"target\": \"https://localhost:8000\",\n \"secure\": false\n }\n }\n}\n```\n\nThis functionality is implemented as a *transparent proxy*, hence a request to\n`http://localhost:7357/api/posts.json` will be proxied to `http://localhost:4200/api/posts.json` without removing the `/api` prefix. Setting the `secure` option to `false` as in the above `/xmlapi` configuration block will ignore TLS certificate validation and allow tests to successfully reach that URL even if testem was launched over HTTP. Other available options can be found here: https://github.com/nodejitsu/node-http-proxy#options\n\nTo limit the functionality to only certain content types, use \"onlyContentTypes\".\n\nExample Projects\n----------------\n\nI've created [examples](https://github.com/testem/testem/tree/master/examples/) for various setups\n\n* [Simple QUnit project](https://github.com/testem/testem/tree/master/examples/qunit_simple)\n* [Simple Jasmine project](https://github.com/testem/testem/tree/master/examples/jasmine_simple)\n* [Jasmine 2](https://github.com/testem/testem/tree/master/examples/jasmine2)\n* [Custom Jasmine project](https://github.com/testem/testem/tree/master/examples/jasmine_custom)\n* [Custom Jasmine project using Require.js](https://github.com/testem/testem/tree/master/examples/jasmine_requirejs)\n* [Simple Mocha Project](https://github.com/testem/testem/tree/master/examples/mocha_simple)\n* [Mocha + Chai](https://github.com/testem/testem/tree/master/examples/mocha_chai_simple)\n* [Hybrid Project](https://github.com/testem/testem/tree/master/examples/hybrid_simple) - Mocha tests running in both the browser and Node.\n* [Buster.js Project](https://github.com/testem/testem/tree/master/examples/buster)\n* [Coffeescript Project](https://github.com/testem/testem/tree/master/examples/coffeescript)\n* [Browserify Project](https://github.com/testem/testem/tree/master/examples/browserify)\n* [JSHint Example](https://github.com/testem/testem/tree/master/examples/jshint)\n* [Custom Test Framework](https://github.com/testem/testem/tree/master/examples/custom_adapter)\n* [Tape Example](https://github.com/testem/testem/tree/master/examples/tape_example)\n* [BrowserStack Integration](https://github.com/testem/testem/tree/master/examples/browserstack) **bleeding edge**\n* [SauceLabs Integration](https://github.com/testem/testem/tree/master/examples/saucelabs) **bleeding edge**\n* [Code Coverage with Istanbul](https://github.com/testem/testem/tree/master/examples/coverage_istanbul) **bleeding edge**\n\nKnown Issues\n------------\n\n1. On Windows, Mocha fails to run under Testem due to an [issue](https://github.com/joyent/node/issues/3871) in Node core. Until that gets resolved, I've made a [workaround](https://github.com/airportyh/mocha/tree/windowsfix) for Mocha. To install this fork of Mocha, do\n\n npm install https://github.com/airportyh/mocha/tarball/windowsfix -g\n\n2. If you are using prototype.js version 1.6.3 or below, you will [encounter issues](https://github.com/testem/testem/issues/130).\n\nContributing\n------------\n\nIf you want to [contribute to the project](https://github.com/testem/testem/blob/master/CONTRIBUTING.md), I am going to do my best to stay out of your way.\n\nRoadmap\n-------\n\n1. [BrowserStack](http://www.browserstack.com/user/dashboard) integration - following [Bunyip](http://www.thecssninja.com/javascript/bunyip)'s example\n2. Figure out a happy path for testing on mobile browsers (maybe BrowserStack).\n\nCore Maintainer(s)\n------------------\n\n* [Johannes Würbach](https://github.com/johanneswuerbach)\n\nCommunity\n---------\n\n* **Mailing list**: \n\nCredits\n-------\n\nTestem depends on the following great software\n\n* [Jasmine](http://jasmine.github.io/)\n* [QUnit](http://code.google.com/p/jqunit/)\n* [Mocha](http://mochajs.org/)\n* [Node](http://nodejs.org/)\n* [Socket.IO](http://socket.io/)\n* [PhantomJS](http://www.phantomjs.org/)\n* [Node-Tap](https://github.com/isaacs/node-tap)\n* [Node-Charm](https://github.com/substack/node-charm)\n* [Node Commander](http://tjholowaychuk.com/post/9103188408/commander-js-nodejs-command-line-interfaces-made-easy)\n* [JS-Yaml](https://github.com/nodeca/js-yaml)\n* [Express](http://expressjs.com/)\n* [jQuery](http://jquery.com/)\n* [Backbone](http://backbonejs.org/)\n", "readmeFilename": "README.md", "repository": { "type": "git", "url": "git://github.com/testem/testem.git" }, "scripts": { "browser-tests": "cd examples/saucelabs/ && ../../testem.js ci -d", "cover": "cover run ./node_modules/.bin/_mocha tests/*_tests.js tests/**/*_tests.js; cover report html; open cover_html/index.html", "install:all": "npm install && npm install phantomjs-prebuilt", "integration": "node ./bin/run-integration.js", "lint": "eslint .", "test": "./bin/run-tests.js", "testem-tests": "mocha --opts tests/mocha.opts tests/*_tests.js tests/**/*_tests.js" }, "version": "1.18.4" }