testing-polyfills.md

Question on JS testing for Polyfills

First off, I'm not great at testing; I'll come right out and say that. But I've had a few issues lately and am curious how I'd automate testing to safeguard features. Here's the scenario:

On the beta signup form for DayTrip, I wanted to use the new fetch() API as a replacement for jQuery and $.ajax. Using this across all browsers requires two polyfills, a Fetch Polyfill and a Promises Polyfill. The form has has broken twice now which is not ideal for a new product.

• First time was just ignorance, didn't realize I needed a Promise polyfill for some modern browsers, even tho that's documented on the Fetch polyfill.
• Second time was a botched Asset Pipeline. The polyfills weren't included in my home.js, maybe due switching to rails_12factor, still not sure.

	Edge	Mobile Safari	Chrome
Promises	❌	😄	😄
Fetch	❌	❌	😄

Another similar situation I have is with the <picture> element:

	Edge	Mobile Safari	Chrome
srcset	❌	😄	😄
<picture>	❌	❌	😄

Different browers need different levels of polyfilling. So my question is this:

1. Is it possible to automate testing that necessary polyfills exist as apart of an Integration test?
2. Is it possible to automate that across multiple platforms and browsers? Or is the only way to test to manually click through each form on each browser?
3. Even if I did the testing and the Asset Pipeline didn't inclulde and minify the correct files, would JS testing be able to detect that?
4. Is this out of scope for what I should be testing? What's a better way?

I would do something along the lines of https://www.jonathanfielding.com/unit-test-your-code-across-multiple-browsers-with-browserstack/: Writing a test (using QUnit, e.g.) and running it on a service like Browserstack or Saucelabs. Ideally integrated with a CI environment like Travis.

Automated integration testing across browsers is the holy grail. If you can figure out how to do it I would definitely go that way.

If the polyfill libraries are well tested, testing that they load is a decent idea. If you don't quite trust their tests, or if you want some extra assurance, you could write some really low level unit tests to ensure the APIs behave as you expect and run those across multiple browsers, e.g., test that a promise is created correctly using the functions you're polyfilling. That would be a lot harder with picture though; the tests for the polyfill should really be in the polyfill itself.

From your description I think you want integration tests run on a bunch of browsers. I've heard good things about Saucelabs, but haven't used it myself. You might want to set these long running tests as nightlies, pre-deploy, and on request (maybe before you open a PR), since it's going to be a pain to wait for your suite to run on 10 browsers every time you want to push a commit and check that it works.

@backflip Cool. Knowing you can programmatically hit BrowserStack is sweet. Definitely going to try to make that happen (even just locally), but I might have to get on some CI service.

@robwierzbowski Testing the Polyfill seems a bit redundant, but maybe in these types of sensitive situations I could checkPromises() and checkFetch() and then do something like the above to run through BrowserStack.