Insanely fast, full-stack, headless browser testing using Node.js


Zombie 4.x is tested to work with io.js 1.6 or later. If you need to use Node 0.12 or earlier, consider using Zombie 2.x.

If you're going to write an insanely fast, headless browser, how can you not call it Zombie? Zombie it is.

Zombie.js is a lightweight framework for testing client-side JavaScript code in a simulated environment. No browser required.

Let's try to sign up to a page and see what happens:

const Browser = require('zombie');
// We're going to make requests to http://example.com/signup 
// Which will be routed to our test server localhost:3000 
Browser.localhost('example.com', 3000);
describe('User visits signup page', function() {
  const browser = new Browser();
  before(function(done) {
    browser.visit('/signup', done);
  describe('submits form', function() {
    before(function(done) {
        .fill('email',    'zombie@underworld.dead')
        .fill('password', 'eat-the-living')
        .pressButton('Sign Me Up!', done);
    it('should be successful', function() {
    it('should see welcome page', function() {
      browser.assert.text('title', 'Welcome To Brains Depot');

This example uses the Mocha testing framework, but Zombie will work with other testing frameworks. Since Mocha supports promises, we can also write the test like this:

const Browser = require('zombie');
// We're going to make requests to http://example.com/signup 
// Which will be routed to our test server localhost:3000 
Browser.localhost('example.com', 3000);
describe('User visits signup page', function() {
  const browser = new Browser();
  before(function() {
    return browser.visit('/signup');
  describe('submits form', function() {
    before(function() {
        .fill('email',    'zombie@underworld.dead')
        .fill('password', 'eat-the-living');
      return browser.pressButton('Sign Me Up!');
    it('should be successful', function() {
    it('should see welcome page', function() {
      browser.assert.text('title', 'Welcome To Brains Depot');

Well, that was easy.

To install Zombie.js you will need io.js:

$ npm install zombie --save-dev

Methods for making assertions against the browser, such as browser.assert.element('.foo').

See Assertions for detailed discussion.

You can use this to set the HTTP Referer header.

Access to history of retrieved resources. See Resources for detailed discussion.

Access to the pipeline for making requests and processing responses. Use this to add new request/response handlers the pipeline for a single browser instance, or use Pipeline.addHandler to modify all instances. See Pipeline.

Array of all open tabs (windows). Allows you to operate on more than one open window at a time.

See Tabs for detailed discussion.

The proxy option takes a URL so you can tell Zombie what protocol, host and port to use. Also supports Basic authentication, e.g.:

browser.proxy = 'http://me:secret@myproxy:8080'

Collection of errors accumulated by the browser while loading page and executing scripts.

Allows you to make requests against a named domain and HTTP/S port, and will route it to the test server running on localhost and unprivileged port.

For example, if you want to call your application "example.com", and redirect traffic from port 80 to the test server that's listening on port 3000, you can do this:

Browser.localhost('example.com', 3000)
browser.visit('/path', function() {
=> 'http://example.com/path'

The first time you call Browser.localhost, if you didn't specify Browser.site, it will set it to the hostname (in the above example, "example.com"). Whenever you call browser.visit with a relative URL, it appends it to Browser.site, so you don't need to repeat the full URL in every test case.

You can use wildcards to map domains and all hosts within these domains, and you can specify the source port to map protocols other than HTTP. For example:

// HTTP requests for example.test www.example.test will be answered by localhost 
// server running on port 3000 
Browser.localhost('*.example.test', 3000);
// HTTPS requests will be answered by localhost server running on port 3001 
Browser.localhost('*.example.test:443', 3001);

The underlying implementation hacks net.Socket.connect, so it will route any TCP connection made by the Node application, whether Zombie or any other library. It does not affect other processes running on your machine.

You can use this to customize new browser instances for your specific needs. The extension function is called for every new browser instance, and can change properties, bind methods, register event listeners, etc.

Browser.extend(function(browser) {
  browser.on('console', function(levelmessage) {
  browser.on('log', function(levelmessage) {

To make life easier, Zombie introduces a set of convenience assertions that you can access directly from the browser object. For example, to check that a page loaded successfully:

browser.assert.text('title', 'My Awesome Site');

These assertions are available from the browser object since they operate on a particular browser instance -- generally dependent on the currently open window, or document loaded in that window.

Many assertions require an element/elements as the first argument, for example, to compare the text content (assert.text), or attribute value (assert.attribute). You can pass one of the following values:

  • An HTML element or an array of HTML elements
  • A CSS selector string (e.g. "h2", ".book", "#first-name")

Many assertions take an expected value and compare it against the actual value. For example, assert.text compares the expected value against the text contents of one or more strings. The expected value can be one of:

  • A JavaScript primitive value (string, number)
  • undefined or null are used to assert the lack of value
  • A regular expression
  • A function that is called with the actual value and returns true if the assertion is true
  • Any other object will be matched using assert.deepEqual

Note that in some cases the DOM specification indicates that lack of value is an empty string, not null/undefined.

All assertions take an optional last argument that is the message to show if the assertion fails. Better yet, use a testing framework like Mocha that has good diff support and don't worry about these messages.

The following assertions are available:

Asserts the named attribute of the selected element(s) has the expected value.

Fails if no element found.

browser.assert.attribute('form', 'method', 'post');
browser.assert.attribute('form', 'action', '/customer/new');
// Disabled with no attribute value, i.e. <button disabled> 
browser.assert.attribute('button', 'disabled', '');
// No disabled attribute i.e. <button> 
browser.assert.attribute('button', 'disabled', null);

Asserts that selected element(s) has that and only that class name. May also be space-separated list of class names.

Fails if no element found.

browser.assert.className('form input[name=email]', 'has-error');

Asserts that a cookie exists and has the expected value, or if expected is null, that no such cookie exists.

The identifier is either the name of a cookie, or an object with the property name and the optional properties domain and path.

browser.assert.cookie('flash', 'Missing email address');

Asserts that one element matching selection exists.

Fails if no element or more than one matching element are found.

browser.assert.element('form input[name=email]');
browser.assert.element('form input[name=email].has-error');

Asserts how many elements exist in the selection.

The argument count can be a number, or an object with the following properties:

  • atLeast - Expecting to find at least that many elements
  • atMost - Expecting to find at most that many elements
  • exactly - Expecting to find exactly that many elements
browser.assert.elements('form', 1);
browser.assert.elements('form input', 3);
browser.assert.elements('form input.has-error', { atLeast: 1 });
browser.assert.elements('form input:not(.has-error)', { atMost: 2 });

Evaluates the JavaScript expression in the context of the currently open window.

With one argument, asserts that the value is equal to true.

With two/three arguments, asserts that the returned value matches the expected value.

browser.assert.evaluate('$('form').data('errors').length', 3);

Asserts that the global (window) property has the expected value.

Asserts that selected element(s) have the expected class name. Elements may have other class names (unlike assert.className).

Fails if no element found.

browser.assert.hasClass('form input[name=email]', 'has-error');

Asserts that selected element has the focus.

If the first argument is null, asserts that no element has the focus.

Otherwise, fails if element not found, or if more than one element found.

browser.assert.hasFocus('form input:nth-child(1)');

Asserts that selected element(s) does not have the expected class name. Elements may have other class names (unlike assert.className).

Fails if no element found.

browser.assert.hasNoClass('form input', 'has-error');

Asserts that selected input field(s) (input, textarea, select etc) have the expected value.

Fails if no element found.

browser.assert.input('form input[name=text]', 'Head Eater');

Asserts that at least one link exists with the given selector, text and URL. The selector can be a, but a more specific selector is recommended.

URL can be relative to the current document, or a regular expression.

Fails if no element is selected that also has the specified text content and URL.

browser.assert.link('footer a', 'Privacy Policy', '/privacy');

Asserts the browser was redirected when retrieving the current page.

Asserts the current page loaded successfully (status code 2xx or 3xx).

Asserts the current page loaded with the expected status code.


Asserts that selected element(s) have the expected value for the named style property. For example:

Fails if no element found, or element style does not match expected value.

browser.assert.style('#show-hide.hidden', 'display', 'none');
browser.assert.style('#show-hide:not(.hidden)', 'display', '');

Asserts that selected element(s) have the expected text content. For example:

Fails if no element found that has that text content.

browser.assert.text('title', 'My Awesome Page');

Asserts the current page has the expected URL.

The expected URL can be one of:

  • The full URL as a string
  • A regular expression
  • A function, called with the URL and returns true if the assertion is true
  • An object, in which case individual properties are matched against the URL

For example:

browser.assert.url(new RegExp('^http://localhost/foo/\\w+$'));
browser.assert.url({ pathname: '/foo/bar' });
browser.assert.url({ query: { name: 'joedoe' } });

Not seeing an assertion you want? You can add your own assertions to the prototype of Browser.Assert.

For example:

// Asserts the browser has the expected number of open tabs. 
Browser.Assert.prototype.openTabs = function(expectedmessage) {
  assert.equal(this.browser.tabs.length, expected, message);

Or application specific:

// Asserts which links is highlighted in the navigation bar 
Browser.Assert.navigationOn = function(linkText) {
  this.assert.text('.navigation-bar a.highlighted', linkText);

Are delicious. Also, somewhat tricky to work with. A browser will only send a cookie to the server if it matches the request domain and path.

Most modern Web applications don't care so much about the path and set all cookies to the root path of the application (/), but do pay attention to the domain.

Consider this code:

browser.setCookie(name: 'session', domain: 'example.com', value: 'delicious');
browser.visit('http://example.com', function() {
  const value = browser.getCookie('session');
  console.log('Cookie', value);

In order for the cookie to be set in this example, we need to specify the cookie name, domain and path. In this example we omit the path and choose the default /.

To get the cookie in this example, we only need the cookie name, because at that point the browser has an open document, and it can use the domain of that document to find the right cookie. We do need to specify a domain if we're interested in other cookies, e.g for a 3rd party widget.

There may be multiple cookies that match the same host, for example, cookies set for .example.com and www.example.com will both match www.example.com, but only the former will match example.com. Likewise, cookies set for / and /foo will both match a request for /foo/bar.

getCookie, setCookie and deleteCookie always operate on a single cookie, and they match the most specific one, starting with the cookies that have the longest matching domain, followed by the cookie that has the longest matching path.

If the first argument is a string, they look for a cookie with that name using the hostname of the currently open page as the domain and / as the path. To be more specific, the first argument can be an object with the properties name, domain and path.

The following are equivalent:

browser.getCookie({ name: 'session',
                    domain: browser.location.hostname,
                    path: browser.location.pathname });

getCookie take a second argument. If false (or missing), it returns the value of the cookie. If true, it returns an object with all the cookie properties: name, value, domain, path, expires, httpOnly and secure.

Returns an object holding all cookies used by this browser.

Dumps all cookies to standard output, or the output stream.

Deletes a cookie matching the identifier.

The identifier is either the name of a cookie, or an object with the property name and the optional properties domain and path.

Deletes all cookies.

Returns a cookie matching the identifier.

The identifier is either the name of a cookie, or an object with the property name and the optional properties domain and path.

If allProperties is true, returns an object with all the cookie properties, otherwise returns the cookie value.

Sets the value of a cookie based on its name.

Sets the value of a cookie based on the following properties:

  • domain - Domain of the cookie (requires, defaults to hostname of currently open page)
  • expires - When cookie it set to expire (Date, optional, defaults to session)
  • maxAge - How long before cookie expires (in seconds, defaults to session)
  • name - Cookie name (required)
  • path - Path for the cookie (defaults to /)
  • httpOnly - True if HTTP-only (not accessible from client-side JavaScript, defaults to false)
  • secure - True if secure (requires HTTPS, defaults to false)
  • value - Cookie value (required)

Just like your favorite Web browser, Zombie manages multiple open windows as tabs. New browsers start without any open tabs. As you visit the first page, Zombie will open a tab for it.

All operations against the browser object operate on the currently active tab (window) and most of the time you only need to interact with that one tab. You can access it directly via browser.window.

Web pages can open additional tabs using the window.open method, or whenever a link or form specifies a target (e.g. target=_blank or target=window-name). You can also open additional tabs by calling browser.open. To close the currently active tab, close the window itself.

You can access all open tabs from browser.tabs. This property is an associative array, you can access each tab by its index number, and iterate over all open tabs using functions like forEach and map.

If a window was opened with a name, you can also access it by its name. Since names may conflict with reserved properties/methods, you may need to use browser.tabs.find.

The value of a tab is the currently active window. That window changes when you navigate forwards and backwards in history. For example, if you visited the URL '/foo' and then the URL '/bar', the first tab (browser.tabs[0]) would be a window with the document from '/bar'. If you then navigate back in history, the first tab would be the window with the document '/foo'.

The following operations are used for managing tabs:

Returns an array of all open tabs.

Returns the tab with that index number.

Returns the tab with that name.

Closes all tabs.

This is a read/write property. It returns the currently active tab.

Can also be used to change the currently active tab. You can set it to a window (e.g. as currently returned from browser.current), a window name or the tab index number.

Dump a list of all open tabs to standard output, or the output stream.

Returns the index of the currently active tab.

Returns the number of currently opened tabs.

Opens and returns a new tab. Supported options are:

  • name - Window name.
  • url - Load document from this URL.

Returns the currently active window, same as browser.tabs.current.

To see what your code is doing, you can use console.log and friends from both client-side scripts and your test code.

To see everything Zombie does (opening windows, loading URLs, firing events, etc), set the environment variable DEBUG=zombie. Zombie uses the debug module. For example:

$ DEBUG=zombie mocha

You can also turn debugging on from your code (e.g. a specific test you're trying to troubleshoot) by calling browser.debug().

Some objects, like the browser, history, resources, tabs and windows also include dump method that will dump the current state to the console, or an output stream of your choice. For example:


If you want to disable console output from scripts, set browser.silent = true or once for all browser instances with Browser.silent = true.

Each browser instance is an EventEmitter, and will emit a variety of events you can listen to.

Some things you can do with events:

  • Trace what the browser is doing, e.g. log every page loaded, every DOM event emitted, every timeout fired
  • Wait for something to happen, e.g. form submitted, link clicked, input element getting the focus
  • Strip out code from HTML pages, e.g remove analytics code when running tests
  • Add event listeners to the page before any JavaScript executes
  • Mess with the browser, e.g. modify loaded resources, capture and change DOM events

Emitted whenever a message is printed to the console (console.log, console.error, console.trace, etc).

The first argument is the logging level, and the second argument is the message.

The logging levels are: debug, error, info, log, trace and warn.

Emitted when this window becomes the active window.

Emitted when this window is closed.

Emitted when the event loop goes empty.

Error when loading a resource, or evaluating JavaScript.

Emitted after JavaScript code is evaluated.

The first argument is the JavaScript function or code (string). The second argument is the result. The third argument is the filename.

Emitted whenever a DOM event is fired on the target element, document or window.

Emitted whenever an element receives the focus.

Event loop is idle.

Emitted when this window is no longer the active window.

Emitted whenever an interval (setInterval) is fired.

The first argument is the function or code to evaluate, the second argument is the interval in milliseconds.

Emitted when a link is clicked.

The first argument is the URL of the new location, the second argument identifies the target window (_self, _blank, window name, etc).

Emitted when a document has been loaded into a window or frame.

This event is emitted after the HTML is parsed, and some scripts executed.

Emitted when a document is about to be loaded into a window or frame.

This event is emitted when the document is still empty, before parsing any HTML.

Emitted when a new window is opened.

Emitted when following a redirect.

Emitted before making a request to retrieve a resource.

The first argument is the request object. See Resources for more details.

Emitted after receiving the response (excluding redirects).

The first argument is the request object, the second argument is the response object. See Resources for more details.

Browser received server initiated event (e.g. EventSource message).

Event loop fired a setInterval event.

Event loop fired a setTimeout event.

Emitted whenever a form is submitted.

The first argument is the URL of the new location, the second argument identifies the target window (_self, _blank, window name, etc).

Emitted whenever a timeout (setTimeout) is fired.

The first argument is the function or code to evaluate, the second argument is the delay in milliseconds.

Called for each XHR event (progress, abort, readystatechange, loadend, etc).

Zombie supports HTTP basic access authentication. To provide the login credentials:

browser.on('authenticate', function(authentication) {
  authentication.username = 'myusername';
  authentication.password = 'mypassword';

Zombie can retrieve with resources - HTML pages, scripts, XHR requests - over HTTP, HTTPS and from the file system.

Most work involving resources is done behind the scenes, but there are few notable features that you'll want to know about. Specifically, if you need to do any of the following:

  • Inspect the history of retrieved resources, useful for troubleshooting issues related to resource loading
  • Request resources directly, but have Zombie handle cookies, authentication, etc
  • Implement new mechanism for retrieving resources, for example, add new protocols or support new headers (see Pipeline)

Each browser provides access to the list of resources loaded by the currently open window via browser.resources. You can iterate over this list just like any JavaScript array.

Each resource provides three properties:

  • request - The request object
  • response - The resource object (if received)
  • error - The error generated (no response)

The request object is based on the Fetch API Request object.

The response object is based on the Fetch API Response object. Note that the fetch API has the property status, whereas Node HTTP module uses statusCode.

You can use the browser directly to make requests against external resources. These requests will share the same cookies, authentication and other browser settings (also pipeline).

The fetch method is based on the Fetch API.

For example:

  .then(function(response) {
    console.log('Status code:', response.status);
    if (response.status === 200)
      return response.text();
  .then(function(text) {
    console.log('Document:', text);
  .catch(function(error) {
    console.log('Network error');

To access the response document body as a Node buffer, use the following:

  .then(Buffer) // arrayBuffer -> Buffer 
  .then(function(buffer) {
    assert( Buffer.isBuffer(buffer) );

Dumps the resources list to the output stream (defaults to standard output stream).

Zombie uses a pipeline to operate on resources. You can extend that pipeline with your own set of handlers, for example, to support additional protocols, content types, special handlers, etc.

The pipeline consists of a set of handlers. There are two types of handlers:

Functions with two arguments deal with requests. They are called with the browser and request object. They may modify the request object, and they may either return null (pass control to the next handler) or return the Response object, or return a promise that resolves to either outcome.

Functions with three arguments deal with responses. They are called with the browser, request and response objects. They may modify the response object, and must return a Response object, either the same as the argument or a new Response object, either directly or through a promise.

To add a new handle to the end of the pipeline:

browser.pipeline.addHandler(function(browserrequest) {
  // Let's delay this request by 1/10th second 
  return new Promise(function(resolve) {
    setTimeout(resolve, 100);

You can add handlers to all browsers via Pipeline.addHandler. These handlers are automatically added to every new browser.pipeline instance.

Pipeline.addHandler(function(browserrequestresponse) {
  // Log the response body 
  console.log('Response body: ' + response.body);