Zuul.yml

The .zuul.yml file lives in each project directory and contains per-project test settings.

The following fields are supported

ui (required)

Identifies the testing framework zuul will use when orchestrating the test harness. Currently supported values: qunit, mocha-tdd, mocha-qunit, mocha-bdd

ui: qunit

ui: mocha-tdd

browsers (required)

List of browsers to test in the cloud. Each entry starts with a - name field and must contain a version field and an optional platform field. If the platform field is omitted, a default platform will be selected.

browsers:
  - name: chrome
    version: latest
  - name: safari
    version: latest

Specific version of a browser on a specific platform

browsers:
  - name: chrome
    version: 28
    platform: Windows XP

Range of versions of a browser

browsers:
  - name: firefox
    version: 14..latest

html (optional)

The html field allows you to inject custom html into the page. This is useful for testing app frameworks where you might want to specify some custom template logic. The html is inserted at the start of the body. See the emberjs example.

html: ./test/templates.html

scripts (optional)

A list of files or url to load into <script> tags on the page before tests run. This would be used to load jquery or other globals if your module and test code is not self contained.

scripts:
  - "http://cdnjs.cloudflare.com/ajax/libs/jquery/1.10.2/jquery.js"
  - "http://cdnjs.cloudflare.com/ajax/libs/handlebars.js/1.0.0/handlebars.min.js"
  - "http://builds.emberjs.com/tags/v1.2.0-beta.1/ember.js"
  - "app.js"

See the ember w/qunit example for sample tests which use scripts.

server (optional)

This field can point to an optional shell command or javascript file to run as a testing support server. This is used to make testing with real ajax and websocket requests possible. Your command will be run with the ZUUL_PORT environment variable set to a port number you MUST use. If your server does not listen on this PORT then your test requests won't be able to reach it.

server: ./test/support/server.js

I recommend writing simple support servers using expressjs. However, any shell command will be run so servers in ruby, python, etc are also supported.