Regardless, I am happy to have gotten testing of Polymer on IE working, but I still have a few outstanding questions that I'd like answered before moving on to less traumatizing subjects. My IE Polymer tests work with karma-ie-launcher and IE10. I would like to be able to run karma-webdriver-launcher and use it on both IE10 and IE11.

Switching to karam-webdriver-launcher would mean no more WordPad coding (since the code resides on the host machine, not the guest VM), so I will start there. I already have Karma configuration in place that should work:

This indexOf failure seems to come from calling a “contains” matcher in my tests on undefined values. As I found yesterday, that is more of a symptom of larger Karma issues than individual test failures.

The el here is my <x-pizza> pizza building Polymer element. The asyc() method from Polymer accepts a callback that will be invoked after Polymer has updated the UI and all bound variables. That works on its own in Chrome and Firefox, but, as I found yesterday, Polymer's IE implementation seems to have a bug that requires an additional browser event loop before everything is ready.

And, with that set-timeout-zero, I have my IE WebDriver tests passing:

So what about IE11? Things were even worse in that VM because I have yet to get the console in the Web Developer Tools to start successfully, making troubleshooting next to impossible. Perhaps the set-timeout-zero fix works there as well?

In the Windows VM, I fire up a good old command prompt (I can't believe that it hasn't changed in 10+ years). In there, I start WebDriver via the webdriver node.js package:

C:\Users\IEUser>webdriver-manager start --seleniumPort 4411

I run the IE10 WebDriver on port 4410 and the IE11 WebDriver on 4411. So I update my karma.conf.js accordingly:

For whatever reason, it seems that my Polymer element is taking more than the usual single event loop to register in IE11. A single event loop is all that is required in Chrome, Firefox, and IE10. But IE11 requires an additional 10 milliseconds before it is ready:

And this seems to work reliably. I run through 10 single-run rounds of tests and all pass each time. If I drop down to 2 milliseconds, then tests start failing on occasion. If I really, really needed IE testing, I might bump these timeout delays for 50 or 100 milliseconds. For now, I'm just happy with a reliable local solution.

So it is ugly. It is rife with callbacks, set-timeout-zeros and other more arbitrary set-timeouts. But I have a working solution for testing Polymer on Internet Explorer. And I didn't even need to fire up WordPad.