In a previous post on the Outside Developer Blog, we talked about our development workflow and how it includes a testing process. Over the past couple of months, we’ve been experimenting with making our testing process more efficient and helpful for our developers. In our research, we came across a tool from Google called Puppeteer, "a high level API to control Chrome or Chromium over the DevTools Protocol." In more basic terms, Puppeteer allows you to do anything you would do manually in Chrome but through code. Need a screenshot? Want to test form inputs? Need to test your web speed? Puppeteer can do all that and more.
Our tests used to be built using a tool called Casper that ran on top of a Selenium headless browser. Our experience with Casper has unfortunately been troublesome with tests failing for no apparent reason and inconsistencies across runs. Our tests were becoming so finicky and troublesome that we started commenting out tests that we knew were succeeding in the browser but failed for Casper. We still needed our builds but Casper was not being a reliable source of information for passing and failing tests. This was obviously not a good sign, bad practice, and would lead to trouble down the line.
After experimenting and researching Puppeteer, we arrived at two questions:
Should we change our tests from Casper to Puppeteer?
Would Puppeteer be better and thus worth the switch?
As a team we decided it would at least be worth implementing one of our tests in Puppeteer and viewing the results.
Puppeteer + Mocha + Chai
Getting started with Puppeteer, Mocha, and Chai proved to be extremely straightforward and easy to follow. We were able to convert a previously failing Casper test to a working Puppeteer test within a few hours. After we were able to get one test suite running, we worked on converting all of our test to Puppeteer and removing Casper from our process. In this shift, we were able to provide developers with more tools to help debug tests that are failing. Puppeteer has the option to run Chrome in a non-headless state, so a browser window would open up with the test parameters and allow a developer to interact with the test. We also were able to implement a screenshot workflow that takes screenshots of the webpages for any failing test. Both of these options are simple parameters passed to the testing script. Our experience so far has been happy and successful and we look forward to diving deeper into Puppeteer.
Be sure to check out Part 2 to learn how we implemented Puppeteer, Mocha, and Chai to create our new test suite.