-
Notifications
You must be signed in to change notification settings - Fork 87
Zuul.yml
The .zuul.yml
file lives in each project directory and contains per-project test settings.
The following fields are supported
Identifies the testing framework zuul will use when orchestrating the test harness. Currently supported values: qunit, mocha-tdd, mocha-qunit, mocha-bdd, tape
ui: qunit
ui: mocha-tdd
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
Disjoint versions
browsers:
- name: firefox
version: [19, 20]
Disjoint with ranges
browsers:
- name: firefox
version: [19, 20, 23..latest]
Float version numbers
browsers:
- name: iPhone
version: '8.0..latest'
Float version numbers should be quoted.
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
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.
You can set any of the configuration elements in the list below, and they'll be passed to browserify
.
plugin
external
ignore
exclude
transform
add
require
You can pass options to any of them, and you can use multiples as the configuration object is treated as an array!
browserify:
- plugin: proxyquire-universal
- require: ./some-file.js
expose: intimidate
entry: true
- external: ./some-module.js
- transform: brfs
- transform: jadeify
You can also configure what's passed as the opts
to browserify(opts)
by adding an item with the options
property.
browserify:
- transform: coffeeify
- options:
extensions:
- .js
- .json
- .coffee
Transform options can also be provided like so:
browserify:
- transform:
name: reactify
es6: true # option passed to reactify
- transform: 6to5ify
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. $ZUUL_PORT can also be used as part of the arguments, enabling the use of command-line http servers:
# Assuming python is installed
server: "python -m SimpleHTTPServer $ZUUL_PORT"
# If http-server is available, e.g. npm install -g http-server
server: "http-server -p $ZUUL_PORT"
Selenium (and Sauce Labs) support running Firefox instances with custom user profiles. This allows you to configure anything you can change in about:config
programmatically for a test run. In zuul
, you can set these options in .zuul.yml
with a section under any Firefox browser entry. For instance:
browsers:
- name: firefox
version: latest
firefox_profile:
webgl.force-enabled: true
YAML values within the firefox_profile
section will be transformed into a Firefox profile, zipped, and uploaded to the test worker.