My current plan is to work through every chapter in Patterns in Polymer, getting the code and tests up to date with the latest Polymer and Karma + Jasmine. Once I have a regular build in place, I will revisit each chapter's content to ensure that it too is up-to-snuff, then perhaps add a chapter or two.
As an aside, I have encountered my share of annoyances with minor Polymer breakages but I can accept those—this is, after all an alpha release of the library. More frustrating is the syntax in Jasmine changing with every patch release (e.g.
and.returnValue()is my latest favorite). Between this and major syntax changes in other testing libraries for no apparent reason, it almost enough to put me off testing.
xvfb-runrun script to execute tests:
Unfortunately this turns out to be the cause of my Dart failure:
# Run the Karma tests xvfb-run karma start --single-run --log-level warn
Ugh. I start dreaming up how I might retry the build with a different port or additional delay or maybe even run only one build at a time. Mercifully, before I get around to attempting to implement any of that, I read the
xvfb-runman page (to be honest, I was reading it to figure out how to implement some of those crazy ideas). In addition to making it easy to wrap processes inside a windowing environment, the
xvfb-runscript also has a flag to do just what I need:
Try to get a free server number, starting at 99, or the argument to --server-num.
So in the end, all I need to do is add the
-aswitch to my tests:
# Run the Karma tests xvfb-run -a karma start --single-run --log-level warn
Xlib: extension "RANDR" missing on display ":99".During most of the test runs, I see the message on port
:99, but on one I see:
Xlib: extension "RANDR" missing on display ":100".In other words, the
:99and automatically ran on
With that, I can get back to fixing tests and code without the worry of seemingly random failures.