Automated cross-browser testing made easy.
Run your QUnit, Mocha or Jasmine tests from the command line with any browser.
For questions or discussion checkout our forums.
You need NodeJS installed in order to use Testee which makes the installation as easy as:
npm install -g testee
testee with your QUnit, Mocha or Jasmine
test HTML page:
The default browser is PhantomJS, just make sure you have it installed anywhere on your system.
To run with different local browsers (e.g. Firefox and Safari) use:
testee tests/qunit.html --browsers firefox,safari
Or run multiple tests in multiple browsers:
testee tests/unit.html tests/components.html --browsers firefox,safari
Note that the browser you are using for testing shouldn't be already running (except for PhantomJS which can be started multiple times).
On the command line, you have the following options available:
--help: output usage information
--version: output the version number
[name]: A comma separated list of browsers you want to run (default:
--root [path|URL]: The server root path or URL the files are relative to
[port]: The port to run the server on (default:
[name]: The name of the reporter to use (default:
[file]: Use this JSON configuration file (can be overwritten by command line options)
[seconds]: The per test timeout (in seconds)
[ms]: When running multiple tests, the time to wait for the browser to shut down before starting it with a new page.
--server: Only run the server
--coverage: Enable code coverage
test.html in the
/var/www/app/ folder using Safari:
testee test.html --root /var/www/app/ --browsers safari
Run the online Underscore QUnit tests in Phantom and Firefox and output code coverage statistics:
testee test/index.html --root http://underscorejs.org --browsers phantom,firefox --coverage
tests/qunit.html with PhantomJS from the current folder, use port
8080 instead of
Spec reporter which prints more detailed test results:
testee tests/qunit.html --port 8080 --reporter Spec
testee.json as the configuration file (see the configuration API
for how this file should look like):
testee tests/mocha.html -c testee.json
tests/jasmine.html using Google Chrome Canary:
testee tests/jasmine.html --browsers canary
Because Testee allows to use different reporters for the test result output it is easy to obtain XUnit
style XML files that integrate with CI servers like Jenkins. Just use the
reporter and write the output into a file. The following example runs
tests/qunit.html in Firefox and writes
the result XML into
testee test/index.html --browsers firefox --reporter XUnit > testresults.xml
You can get more information about the available reporters in the Reporters section.
Testee uses the Node debug module. Detailed debugging information can be enabled
in any environment (command line, Grunt, programatically) by setting the
DEBUG environment variable to
DEBUG=testee:* testee --browsers canary tests/jasmine.html
The following sections describe the available options for
Any options will be merged with the following default configuration:
port: 3996root: processreporter: 'Dot'timeout: 120delay: 1000tunnel:type: 'local'launch:type: 'local'
Every time when running a test, Testee will start a static file server, by default in the current folder. That way, any test HTML file you reference will be loaded properly. The
root option allows you to change
the root path of the static fileserver.
The port for the static file server to start on. This will also be used by Localhost tunneling services. The default is
The time (in seconds) to wait for a test page to report back and after which an error will be thrown. The default is 2 minutes. This timeout might, for example, occurr when the given file doesn't exist the browser didn't start or the localhost tunnel isn't running.
Multiple test files will be run in sequence on the same browser. This option sets the delay (in ms) between launching the browser again with the same file.
reporter option allows you to use all of the console reporters included in the
Mocha testing library.
browsers options are used to set the environment and the browsers you want
to start. Launchpad is the browser launcher library used
by Testee which allows you to start most locally installed browsers as well as Browserstack workers
and even browsers on remote systems running the Launchpad Server.
The most common case will be launching a local browser (which is also the default) with no settings:
"browsers" : "firefox" "safari"
Browserstack hosts virtual machines running specific versions of web browsers. It is an extremely useful tool for cross-browser testing running a remote desktop in you browser. To use BrowserStack via the configuration API you need to provide a username and password:
"launch":"type": "browserstack""username": "your browserstack username""password": "your browserstack password""version": "browserstack API version (recommended: 2)"
To start a worker, you must provide a valid browser object to the
browsers:os: "win"browser: "ie"version: 80os: "win"browser: "ie"version: 110
An example configuration that runs your tests on an iPad Mini and Samsung Galaxy S3 emulator using BrowserStack in a CI environment (outputting XUnit logs) could look like this:
"reporter" : "XUnit""tunnel":"type": "browserstack""key": "your browserstack key""launch":"type": "browserstack""username": "your browserstack username""password": "your browserstack password""version": 2"browsers":"os": "ios""device": "iPad Mini""version": 60"os": "android""device": "Samsung Galaxy S III""version": "4.1"}
coverage options is used to instrument and report code coverage using Istanbul. There are several options available for configuring how code coverage is reported:
The type of reporter(s) to use. Multiple formats are available, including
The directory where the coverage data should be written.
text reports will be written to the console.
List of regex patterns to match files that should be ignored by coverage instrumentation and reporting.
A localhost tunneling service makes your local system available to the outside world. This is great if you want to run tests on another system which can't easily reach your local machine. Testee relies on localhost tunneling services especially for giving Browserstack workers an endpoint to communicate with.
Testee uses the Miner package to provide localhost tunneling which makes it possible to use any of the services Miner currently supports (LocalTunnel, Pagekite and Browserstack). Localtunnel doesn't need any configuration at all and will install itself if you have Ruby available.
If you would like to use Pagekite you need to set it up with your username and then pass it to the
"launch" :"type" : "pagekite""username" : "pagekit user"
It is also possible to use the Browserstack tunnel API which you have to provide with your command line tunnel API key:
"launch" :"type" : "browserstack""key" : "your command line tunnel API key"
For all available tunneling services and options follow up in the Miner documentation.
Testee comes with a Grunt task that takes the same options as described above (
src should be set to your source test files).
The following is an example that runs
public/ as the root folder and
Spec as the reporter in either
BROWSERSTACK_PASSWORDtaken from environment variables
You can also use Testee programmatically from gulp or another Node script.
In most cases there is no need to change your actual test code.
One exception is when you load your testing library using an asynchronous client side loader like Steal or RequireJS because Testee won't know which library adapters to attach. In this case, you need to call
Testee.init() manually once the test library is loaded:
In some testing environments, reporting test progress via REST may work better than socket.io. In this case, you specify a