Headless Tests with Buster.js and Phantom.js
This setup was pieced together via several gists, tweets and articles so I thought it would be good thing to collect it all in a post. http://busterjs.org/docs/browser-testing/ says phantom.js support is “not yet landed in the beta”, but that is the config sugar for doing it through the buster.js config file. It works just fine nonetheless.
We have been moving tests for the frontend projects at work to buster.js instead of JsTestDriver. Mainly because Buster.js is faster and has a richer set of tools built in. JsTestDriver has some annoying bugs too and does not seem to be actively developed these days.
Phantom.js is a 100% headless (as of version 1.6) headless webkit browser engine. It can be used for all kinds of nifty things like taking screenshots of web pages (the whole page, and not just the viewport), scripting interaction with webpages (there’s an example of using Google Maps to find driving directions) and finding the load time of a web page, to name a few cool things.
Installing Buster.js and Phantom.js
Install Phantom.js by downloading it and unpacking the tar-file. If you’re on a mac you can do:
Buster.js is a node module and can be installed by running the following command in a recent node version:
or checking out http://busterjs.org/docs/getting-started/ if you need more handholding. Depending on your platform you may need to adjust your path variable or symlink the buster executables into your $PATH
Running the Tests
So to run some buster tests in phantom I have made a small project with some tests
lib/math.js file is a small object with a simple function, and
test/math-test.js is a test case for that. Nothing fancy there, but I list them for completeness. These files should hold your production code and tests.
The contents of
buster.js (buster config file):
server.sh is a script for starting the buster server and the phantom.js instance, and run the
phantom.js script on startup:
Then we have the
phantom.js script for capturing the browser, in phantom. We also redirect any alerts
to console.log() instead, since we won’t see them.
The last script,
kill-server.sh is for running after the tests and shut everything down again.
Running all these together, after another, we start up a buster server on localhost:1111, start phantomjs and use that to capture the buster server, run the tests, and the kill the server and phantom afterwards.
If you’re running the tests locally, you can leave the server and phantom running. But we want to run them in the CI server, so we clean up after tests are run.
Running on Jenkins
We run the build of this project in Jenkins and want to display the test results there, along with csslint, jslint and other quality checks. Buster.js has a nifty command line switch for outputting junit compatible xml, which Jenkins reads out of the box. For instance this command, instead of plain buster-test in Jenkins, with config for the violations plugin pointing to the file, will graph the test results nicely.
The scripts can also of course be configured to run through npm, if you want.
That’s it, happy phantom.js and buster.js hacking!blog comments powered by Disqus