Skip to content


Visual regression testing with Wraith

I’ve had a play with this before, but new machine, new set-up, this time I’ll document it…

First, what is Visual Regression Testing?

Simply, the visual comparison of two versions of a page, and highlighting any differences. It’s spot the difference for web folks.

It’s important to note this compliments other testing, catching the sort of difference easily missed in QA and by functional testing (be that in in CI or elsewhere). It also still requires someone to actually look and the output. Humans are significantly better at spotting things that are wrong, but they first need to be presented with the possibility that something could be wrong.

Okay, what is Wraith?

Wraith is a tool created by the BBC for automating some aspects visual regression testing.

Given two domains, it can compare pages between those domains. Wraith will highlight differences between pages (for example, a page on your local dev or pre-prod environment and a production environment) and save these as a screenshot for you to manually check. It will also flag unexpected percentage of difference, indicating if you have a potential problem.

Screenshot of Wraith output
Wraith output
Wraith output screenshot
Wraith visual output screenshot

Installing Wraith

  • Install HomeBrew. This is will take all the pain away. HomeBrew is a package manager for macOS and saves you having to mess around with installation paths and version management.
  • Install ImageMagick. This is required by Wraith to generate screenshots for comparison. From a terminal:
brew install imagemagick
  • Intall PhantomJS. This is a headless web browser that will load your site
brew install phantomjs
  • Install Wraith. Wraith itself is a Ruby package, and this assumes you have Ruby installed. Ruby ships with macOS, so we’re good to go:
gem install wraith

Now we have all the bits we need to run Wraith, we need to configure it to run.

You could run wraith setup but I prefer a hand-crafted config. You can save this into a config.yaml folder in your project, or wherever you’re doing CI testing. It should be pretty self-explanatory. Here’s the config for one one my sites:

browser: "phantomjs"
  current:  ""
  dev:   "http://localhost:3001"
  home:     /
  - 320
  - 600x768
  - 768
  - 1024
  - 1280
directory: 'wraith'
fuzz: '20%'
Default: 0
threshold: 5
  template: 'slideshow_template'
  thumb_width:  200
  thumb_height: 200
mode: diffs_first

On my particular setup, I have a dev copy running on port 3001 of my local Mac. This could be set to wherever your test environments live (CI environment, for example).

Running Wraith

As we installed a global ruby gem for Wraith and global prerequisites via Homebrew, you can run Wraith from anywhere on your system. It doesn’t have to be in your project folder.

Note: You may actually want to avoid committing your Wraith configuration to your project as it could expose testing URLs and other setup that you don’t want public.

  • Run Wraith with our configuration
wraith capture ./configs/capture.yaml

Wraith terminal screenshot

Wraith terminal screenshot

  • Wraith will provide a summary and will generate a series of screenshots. These can be found (in my case) in ./wraith/home/. These contain screenshots of each URL, a thumbnail, and a 3rd file containing the differences between URL.
  • Wraith also generates a gallery of ./wraith/gallery.html

In my setup I ran Wraith from my project folder, so Wraith’s gallery was served along with that on port 3001

Wraith gallery screenshot


Wraith documentation

Installing HTTP/2 on Ubuntu

The why?

HTTP/2 is a modern protocol that offers big improvement performances over HTTP/1.1. A binary protocol, it effectively streams the data, circumventing the age-old problem of slow sites due to many small assets. This means we can (in many circumstances) remove the necessity of concatenating scripts/CSS or fuss with sprite sheets. HTTP/2 provides potentially faster performance by interleaving the files as they are served. Secondly, HTTP/2 allows for the server to “push” files to the browser that it thinks the browser will need next. This can work in tandem with a new preload attribute in your page markup.

Enabling HTTP/2 on Ubuntu

  • First we need to update our Ubuntu install and tell it where to find HTTP
sudo add-apt-repository -y ppa:ondrej/apache2
sudo add-apt-repository -y ppa:ondrej/php5
sudo apt-get update && sudo apt-get dist-upgrade
  • Now we can install HTTP/2
sudo a2enmod http2

Note that for HTTP/2 to work, we need to have previously setup SSL certificates for any domains we want to serve. I covered that here.

  • Next we’ll need to tell Apache that we want to let sites be served over the new protocol:
sudo nano /etc/apache2/apache2.conf

Add a section:

# HTTP Protocols
Protocols h2 http/1.1
  • Save the file. Now we’ll need to restart Apache for the change to stick:
sudo service apache2 restart

You shouldn’t need to do anything else. Browsers will automatically try the newer protocol and the server should serve up files with no changes to your codebase.

To test whether HTTP/2 is working, you can check in Chrome’s dev tools under networking. If the Protocol column is missing, right-click the columns to add it. H2 is HTTP/2.

Screenshot of networking tool in Chrome

Dev Notes

As ever, when playing with stuff like this, take a snapshot of your machine first…

A quick guide to hosting WordPress sites on Ubuntu

I’ve recently set-up a clutch of new WordPress sites on an Ubuntu server. This post pulls together my notes for doing it with minimal fuss.


  • SSH access to the server
  • Admin level user for editing Apache settings
  • A user with permission to create databases (root)
  • A domain name already pointed at the IP address of this server
  • Basic knowledge of Nano (file editing)

Setup the database

We’ll assume we know how to get into our database. We’ll be prompted for a password (in this case for the user root):

mysql -uroot -p
CREATE USER 'mysiteuser'@'localhost' IDENTIFIED BY 'passwordhere';
USE mysite;
GRANT ALL PRIVILEGES ON mysite.* TO 'mysiteuser'@'localhost’;

This creates a database called “mysite”, and a user that has full privileges to just that database.

Download WordPress

Now we need to download the latest WordPress release using wget.

tar -xzvf latest.tar.gz
This will result in a folder named wordpress/ in our home folder.
On Ubuntu servers, web sites are usually located in /var/www/. So we’ll create a new folder there for our WordPress site, copy WordPress into that folder, and ensure the web server (Apache) has rights to serve any files.
mkdir /var/www/mysite
cp -r wordpress/ /var/www/mysite
cd /var/www
sudo chown -R www-data:www-data mysite
sudo chmod -R 775 mysite

To check the permissions applied, use ls -ltr.

Setting up the Web Server

Now we need to tell Apache about the site.
cd /etc/apache2/sites-available/
There’s likely a default configuration file already here, or files for other sites already setup. We’ll take a copy of the default one (on an Digital Ocean WordPress droplets this is named 000-default.conf.dpkg-dist) and name for our site:
cp default.conf mysite.conf
We now need to edit this file and ensure that we change any references to our new site and the folder we previously copied it into are correct.
sudo nano mysite.conf
The file should be edited to look similar to this:
<VirtualHost *:80>
 ServerAdmin webmaster@localhost
 DocumentRoot /var/www/mysite

 <Directory /var/www/mysite />
 Options Indexes FollowSymLinks
 AllowOverride All
 Require all granted

 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined

Enabling SSL and starting your site

All moderns sites should also use SSL as it promotes security of our visitors. The default Digital Ocean WordPress droplet comes with this pre-installed, but it’s easy enough to add to Ubuntu yourself. Lets Encrypt* will walk us through the setup.
sudo letsencrypt --apache -d -d
sudo a2ensite mysite
service apache2 reload

Note that we add all the aliases for this site where we want SSL to be enabled (which should include all subdomains!).

That’s our site good to go.

* If Lets Encrypt complains that it’s unable to verify the domain it’s likely that the DNS entries for our domain are not yet resolving (can’t find a server). If we’ve only just setup this domain, we may need to wait up to 24 hours.

Monitoring a site with UptimeRobot

I’m late to this one, but there is a fantastic service called UptimeRobot for monitoring site uptime. A killer feature is the ability to add a simple status page via a subdomain to your site. Example:

First, head over to UptimeRobot and sign up.

Uptime Robot sign-up page

  • There are no sites configured initially, so we need to add one

Adding a site

  • Now you need to decide what site(s) to monitor.

Adding a site to UptimeRobot

  • Once you’ve done this, you can create a custom status page. This can be accessed from clicking My Settings at the top of the page and scrolling down until you find the option for Add Public Status Page.

Adding a custom status Page

  • If you don’t want your public status page to be public, you can enter a password. I left mine blank.

Setup public status page

  • We want this status page to be available on a subdomain of an existing site ( Once the form is complete, we need to edit our DNS record (this will be either where you registered your domain, or your server host) and add a new CNAME record. We point this at

Updating DNS record

  • This should be available almost instantly. Visit the subdomain you created and you’ll see your new status page.

Example public status page

You can continue to add as many sites as you like to this status page, or go back and edit the settings if you decide you don’t want this information to be public. You can also create different status pages, with their own privacy settings –but you’ll need to use a different subdomain for each.