web-component-tester makes testing your web components a breeze!
npm install web-component-tester
web-component-tester makes testing your web components a breeze!
You get a browser-based testing environment, configured out of the box with:
* [Mocha][mocha] as a test framework.
* [Chai][chai] assertions.
* [Async][async] to keep your sanity.
* [Lodash][lodash] (3.0) to repeat fewer things.
* [Sinon][sinon] and [sinon-chai][sinon-chai] to test just your things.
* [test-fixture][test-fixture] for easy fixture testing with tags.
* [accessibility-developer-tools][a11ydevtools] through a11ySuite for simple, automated Accessibility testing.
WCT will run your tests against whatever browsers you have locally installed, or remotely via Sauce Labs.
.html SuitesYour test suites can be .html documents. For example,test/awesomest-tests.html:
``html`
Note that it is _critical_ that you include ../web-component-tester/browser.js
in your test suites. contains all of WCT's client logic (and loads/components/web-component-tester/browser.js
bundled libraries like mocha and chai). You can also load it from the absolute URL .
SuitesAlternatively, you can write tests in separate .js sources. For example,test/awesome-tests.js:
`js`
suite('AwesomeLib', function() {
test('is awesome', function() {
assert.isTrue(AwesomeLib.awesome);
});
});
can be used to reset DOM state between test runs.
`html
`
!Accessibility Suite Test RunRunning Your Tests
$3
The easiest way to run your tests is via the
command line tool. Install
it globally via:`sh
npm install -g web-component-tester
`Make sure that you also have [Java][java] installed and available on your
.The
wct tool will run your tests in all the browsers you have installed. Just
run it:`sh
wct
`By default, any tests under
will be run. You can override this by
specifying particular files (or globs of files) via wct path/to/files.
$3
If you prefer not to use WCT's command line tool, you can also run WCT tests
directly in a browser via a web server of your choosing.
Make sure that WCT's
browser.js is accessible by your web server, and have
your tests load browser.js.The recommended way to fetch these is via Bower:
bower install Polymer/web-component-tester --save
#### Nested Suites
To help support this case, you can also directly define an index that will load
any desired tests:
`html
`_When you use
on the command line, it is generating an index like this for
you based on the suites you ask it to load._
Configuration
The
wct command line tool will pick up custom configuration from a
wct.conf.json file located in the root of your project.
Or, you can specify your own file via the --config-file command line option.
Example: --config-file my.wct.conf.js
If you define your own configuration file, make sure you also provide the correct root if needed.
By default it will use the directory in which the configuration file is found as rootpath, which can result in errors if the file is in a sub directory. It should export the custom configuration:
js
{
"verbose": true,
"plugins": {
"local": {
"browsers": ["chrome", "firefox"]
}
}
}
` for the canonical reference of
configuration properties.You can also specify global defaults (such as
sauce.username, etc) via a
config file located at ~/wct.conf.json.Plugins
Note that by specifying a plugin's configuration, you are letting WCT know that
it should load that plugin. If you wish to provide default configuration for a
plugin, but not enable it, you can have it default to disabled:
Requesting that plugin via
--plugin on the command line (or overriding the
plugin's configuration to disabled: false) will cause the plugin to kick in.$3
The sauce plugin runs your tests on Sauce.
To use the sauce plugin you need to include credentials. To do this, either
set the
SAUCE_USERNAME and SAUCE_ACCESS_KEY environment variables, or
set the username and accessKey fields in the plugins.sauce section of
your wct.conf.json.You can configure the browsers that Sauce will run by setting the
browsers
array in the plugin configuration. The options are the same as the ones documented
on the Sauce Wiki here.
For example:js
{
"plugins": {
"sauce": {
"browsers": [{
"browserName": "microsoftedge",
"platform": "Windows 10",
"version": ""
}, {
"browserName": "internet explorer",
"platform": "Windows 8.1",
"version": "11"
},
{
"browserName": "safari",
"platform": "OS X 10.11",
"version": "9"
}
]
}
}
}
`Variant dependencies
Sometimes you want to run your project's tests against different versions of
your dependencies. For example, suppose there was a significant change in
paper-button version
and you want to confirm that your code works with
v1.4 and v1.5.WCT will serve from the
bower_components directory in your project's root
directory as siblings of your project's root directory. So if you depend on
paper-button, you can import it with the url
../paper-button/paper-button.html.For each directory that WCT detects with a name like
bower_components-${variantName}, it will also run your tests separately
against that variant of your dependencies. So you could use the directory
environment variable option with bower to set
up a directory while developing. WCT would
notice that directory and run your tests in two different variations, one where
../paper-button/paper-button.html gets v1.4, the other where it gets
v1.5.This is implemented by starting one test server per variant, and one copy of each launched browser per test server.
Nitty Gritty
Polymer
By default, WCT will defer tests until
WebComponentsReady has fired. This
saves you from having to wait for elements to upgrade and all that yourself.If you need to test something that occurs before that event, the
testImmediate helper can be used. Or, if you just want tests to run as soon as possible, you can disable the delay by setting WCT.waitForFrameworks = false (though, they are still async due to Mocha).
Mocha
WCT supports Mocha's [TDD][mocha-tdd] (
suite/test/etc) and [BDD][mocha-bdd]
(describe/it/etc) interfaces, and will call mocha.setup/mocha.run for
you. Just write your tests, and you're set.
Chai
Similarly, Chai's [
expect][chai-bdd] and [assert][chai-tdd] interfaces are
exposed for your convenience.
Custom Environments
If you would rather not load WCT's shared environment, or want to have WCT
load additional libraries, you can override the list of scripts loaded. There
are two ways of doing this:
Inside your test code (before
browser.js is loaded):
`html
Dist Tags
next6.9.0-pre.1latest6.9.2