In my previous article, I wrote about how to get started with unit testing in Polymer. The goal was to setup the testing environment and to write your first tests using best practices and taking advantage of the nice tools Polymer offers.

In this article, I’ll cover more advanced topics such as user interaction simulation, automatic testing with Continuous Integration, testing on multiple OS/browsers and more useful tips.

Mock User Interactions

Iron Test Helpers provides a set of methods to simulate mouse or keyboard interaction with an element.

In the example below, you want to be sure that your start button will be disabled after clicking it to avoid users to click on it twice. To do this, you just need to attach a listener to the button reference and use the tap method to simulate the click/tap action.

Accessibility tests

Accessibility is a very important aspect to keep in mind when building new elements or applications. The good news is that testing accessibility in Polymer is a piece of cake.

The a11ySuite() method built in the WCT, runs accessibility audits for a given <test-fixture>. Pass the element reference as an argument to the a11Suite method and you are done. That’s easy, isn’t it?

You can run the same tests using the Accessibility Developer Tools Chrome extension.

Test both Shadow and Shady DOM

Unfortunately, not all browsers support Shadow DOM yet, for that reason Polymer uses Shady DOM instead by default. Shady DOM is compatible with Shadow DOM, but the rendered DOM tree is different. So, if you want to be sure your element works fine in both cases, you need to test it properly.

To do this, you just need to call your test suite twice: once as you normally do and once passing dom=shadow as a query parameter.

CI Integration and Travis Badge

WCT needs a real browser to run and, in the past, I was wondering about how to run my Polymer tests in a continuous integration environment like Travis. Well, It’s easier than you may image, it’s a matter of adding a couple more lines to your .travis.yml file.

First of all, you need to install Bower, web-component-tester, and your element dependencies.
Since Travis has xvfb (X Virtual Framebuffer) and Firefox installed, you just need to export the display and start xvfb.

Remote Testing with Sauce Labs

Sauce Labs allows you to run tests on multiple OS/Browsers in the cloud, and it’s free for open source projects. To start using the service, you need to sign up first.

WCT has a built-in plugin for Sauce Labs so, the only thing you need to do, is to pass some options to WCT:

wct --sauce 'default' --sauce-username <username> --sauce-access-key <access-key>

In the first option (sauce) you can pass a list of OS/browsers you want to run the tests on or, as in the example above, you can set the value to ‘default’ to run the tests in the predefined browsers.

Since you have to be authenticated for the test, you need to pass you username and access key as well. You can find this information in your user settings page.

If you want to specify your own list of browser, a handy way to do it is to list them in a file called wct.conf.json you can put in the root of your project.

Travis + Sauce Labs

If you are interested in learning how to integrate Travis CI with Sauce Labs, watch Rob Dodson in the following Polycasts episode.

Learn more

Most of all example in this article are taken from the <flip-clock> element I wrote. I suggest you to browse the code on Github to get a better overview.

You can learn more about testing Polymer elements watching these great Polycasts episodes.