A fully-automated testing rig #5

##Part 5: Fun with viewports, and THEN some

As I described previously, we nicely externalised our list of viewport sizes, making it really easy to set our viewports for mobile, tablet and desktop tests. Our content appearance tests put this to good use, taking screenshots of the content at mobile, tablet and desktop resolutions. The problem we very quickly ran into was that we frequently ended up with empty screenshots, or sometimes no screenshot at all. This is where the asynchronous fun began.

The official walkthrough for CasperJS' "step stack" gives a very brief introduction to the idea that navigation steps might not be atomic. What you don't necessarily realise though (I didn't!) is that things aren't necessarily atomic when it comes to browsing with PhantomJS, either. So when we first had blank screenshots returned, we went through the rookie mistake of just adding a casper.wait 500 between the resolution change and the capture. This, though, is not reliable.

The proper solution is based on the idea that a viewport change is somewhat like a navigation step; the page is redrawn, though it doesn't necessarily (for us) need to reload all the content. This means that CasperJS' casper.then -> … construct works well for making sure that all the elements are actually drawn in your page before you take that screenshot.

One caveat remains, however. Things like Google Maps can spend quite some time loading their content, so for such special cases a casper.wait 2500 is necessary to ensure everything is displayed correctly. The rest of the time, casper.then -> … seems to work really nicely for ensuring the page is loaded.