Over the past month Zombie.js jumped from 0.10.2 to 0.12.0. These minor change bumps are there to pave the way to a 1.0 release, quite possibly before the end of the year.
Yes. Not a typo.
Let’s talk about the past few minor bumps, before reviewing what’s upcoming.
First there was 0.10.x
The last release was 0.10.3 and brought the site option, which lets you call browser.visit with a relative path. For example:
browser = new Browser(site: "localhost:3000") browser.visit("/testing", function(error, browser) { })
It also fixed uploading of attachments to work with Connect/Express.
Then came 0.11.x with better error handling
Before 0.11, if an error occurred on the page, Zombie would pass it straight to the callback. That would make error catching easy, with the unfortunate side effect of breaking most visits on the first error. And damn, a lot of JavaScript is broken, including libraries from the likes of Google and Facebook.
The new way forward: browser.visit (also browser.wait, browser.clickLink and their ilk) will now plow through page loading, JavaScript executing, and all other good things, collecting errors as they come into browser.errors.
The callback receives null as its first argument, making it easier to work with asynchronous test frameworks like Vows.js. As a convenience, browser.error returns the last error from the list, so to check for errors on the page:
zombie.visit("http://localhost:3000/", function (err, browser, status) { if (browser.error) console.log("Things that went wrong:", browser.errors); if (!browser.success) console.log("Got status code", browser.statusCode); })
When Web servers report errors (404, 500, etc), these are often not HTML pages (well, at least not in development). To make them easier to work with, when you call browser.html or browser.text, you get the page contents, even for non-HTML documents.
Zombie 0.11.x also adds support for HTTP Basic authentication and OAuth 2.0 authentication, brings back support for loading IFrames, fixes viewInBrowser and many other good things.
Last, it adds browser.query (use CSS selector to find an return one element) and browser.queryAll (use CSS selector to return array of matching elements). Please start using browser.queryAll instead of browser.css, I want to use the later for something else in the future.
Followed by 0.12.x and better timeouts
Previously, setTimeout events would fire in the right sequence (earliest to latest) but without actually waiting. This had the benefit that tests would complete faster, and the drawback that some events would fire prematurely (e.g. request timing-out event would fire immediately).
Moving forward, Zombie uses the system setTimeout. The first thing to know, if a timeout fires in a second from now, and your test needs to wait, it will take a second to complete. Asynchronous test frameworks can help here.
You can tell Zombie exactly how long to wait by passing a duration to browser.wait. Or let it do its own thing, in which case it will wait for up 5 seconds, or until the last timeout event fires. This works well for pages that fire timeout events on startup, e.g. jQuery’s onready, or frameworks that use hashbang URLs. Usually they complete within a few milliseconds, so tests are still snappy.
So 0.13.x next?
Very likely. Some stuff I have planned for 0.13.x (besides the usual bug fixes) are adding new types of assertions, of the kind:
browser.assert.success() browser.assert.path("/search") browser.assert.text("h1", "Please signup") browser.assert.field("name", "Assaf")
Another challenge is testing how Zombie deals with real-life JavaScript, e.g. Facebook Connect or the Google Maps API. Running tests against live servers is painful, and that’s on a good network day. Fortunately, node-replay lets us capture responses and replay them when running the tests.
And then?
Finally, one of the stable versions of 0.13.x will be promoted to 1.0.
Jonathan
Assaf