Puppeteer - new headless Chrome library from Google

Tony Atkins tony at raisingthefloor.org
Mon Aug 28 11:19:03 UTC 2017

Hi, Alan.

Thanks for pointing this out.   The first and biggest question that has to
be asked when considering something new, is "why should we use this?"

First, why should we use this and not Testem/gpii-testem
<https://github.com/GPII/gpii-testem>?  Testem already supports a range of
browsers, and works for both unit tests and integration tests.  In my
opinion, the answer is the same as the core use cases for gpii-webdriver
<https://github.com/GPII/gpii-webdriver/>, namely cases in which we need to:

   1. Test keyboard navigation or other complex combinations of keyboard
   input that can't be tested using jQuery.simulate or other means.
   2. Inject arbitrary code into a browser session to enable more complex
   coordination between the client and server side.

So, for those two use cases, can we use Puppeteer?  For Chrome, as far as I
can see the answer is yes.  This is acceptable at the moment, as it's most
important that we test with Chrome/Chromium, which is what we use in
Electron, and what we write our browser plugin for.

Speaking of which, testing the browser plugin is also a key concern.  In
looking at the Puppeteer docs, I didn't see any way of installing a plugin
as part of creating or configuring a new Browser instance.  Thankfully they
do support controlling an existing compatible Chrome instance, which I
assume is how we'd handle that.  As far as I know, we haven't tried loading
an extension using gpii-webdriver yet, although there is a means of
installing an extension
already provided.

So, should we use gpii-webdriver, or Puppeteer? In other words:

   1. Does gpii-webdriver offer some unique value that lets us do things we
   can't with Puppeteer?
   2. Does Puppeteer offer some unique value that lets us do things we
   can't with gpii-webdriver?
   3. Which serves our needs better?

The obvious answer to the first question is that gpii-webdriver is based on
a standard that is not tied to a particular browser, and that multiple
browsers are supported.  However, in practice only Chrome is viable at the
moment, the Edge driver can't send keyboard input
<https://docs.microsoft.com/en-us/microsoft-edge/webdriver-commands>, and
the Firefox driver has problems consistently clicking elements
<https://github.com/mozilla/geckodriver/issues/322>.   There have been
<https://github.com/mozilla/geckodriver/issues/322#issuecomment-324027413> that
recent versions of Firefox/geckodriver have resolved the click issues,
which I will investigate later this week.  My hope is that we will be able
to use Firefox again in the near future.  Edge seems like a longer term
prospect, but they do at least have a road map for adding support.

For the second question, to me the main benefit seems to be that Puppeteer
defaults to using "headless" mode, which I suspect will be much faster and
less disruptive, particularly when running a large suite of tests.  This is
in theory also possible with gpii-webdriver, I will have to look into that
as well.    Alan (or anyone else), please comment if you know of other
unique and useful things that Puppeteer can help us with.

I think this would be a good one to discuss briefly at the next
architecture meeting.  First, I think we should continue the discussion
about what browsers we need to test, as I think the last time we discussed
the topic it was not a long enough or balanced enough discussion (my
apologies to Colin for both).  I'd also like to hear from those working on
OS-level UI tests, just in case that work has progressed to the point where
it offers additional means of testing multiple browsers.



On Thu, Aug 17, 2017 at 4:28 PM, Harnum, Alan <aharnum at ocadu.ca> wrote:

> Potentially of interest: https://github.com/GoogleChrome/puppeteer
> Especially of interest to some may be the keyboard API:
> https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#class-
> keyboard
> "Keyboard provides an api for managing a virtual keyboard. The high level
> api is page.type, which takes raw characters and generates proper keydown,
> keypress/input, and keyup events on your page. For finer control, you can
> use keyboard.down, keyboard.up, and keyboard.sendCharacter to manually fire
> events as if they were generated from a real keyboard."
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170828/e09c570e/attachment.html>

More information about the fluid-work mailing list