Saturday, December 27, 2014

Finally, Testing Polymer in Internet Explorer

I am not fond of Internet Explorer. The reasons are myriad, but not terribly helpful. Despite my dislike, I must admit that it tends to fail in ways that make sense. More often than not, when troubleshooting an “IE bug” I find myself wondering how code works in other browsers. Maybe that will wind up being the case with my Polymer testing woes.

I am running tests for my <x-pizza> Polymer element with Karma. The tests are written with the Jasmine testing library and look like:

But if I fire this element up in a web page, that property is very definitely defined:

After much futzing, I eventually trace this not to my code, but to Polymer's async() method, which comes on the line after the failure message. Things got so wonky that failures in previous tests would break other tests in non-helpful ways. Only after running single tests — with Karma/Jasmine's ddescribe() / iit() — was I able to identify the culprit as async(), which my test uses:

Polymer elements expose this method as a callback mechanism. The supplied callback (my test's assertion in this case), is only invoked once Polymer has updated the UI and all bound variables. This is ideal for testing because the test can be assured that all of the Polymer element's properties and visualizations have been updated—at least in Chrome and Firefox.

In Internet Explorer, it seems that nothing is updated until one more browser event loop. In other words, I have to wait for a setTimeout-0 in addition to the async() callback:

This quite definitely fixes the test. I have other tests that magically pass with the addition of a setTimeout-0, but reliably fail without.

And once again, after some investigation of an “IE Bug,” I am left with a code error that is not IE's fault. This is almost certainly a Polymer bug. The entire point of async() is that the element is updated when the supplied callback is invoked. That I have to wait for another event loop on top of this seems quite wrong.