Will finish in the morning

Testing responsive websites

A whiteboard with test results in different browsers

As many good fellows have already noticed, it’s not enought to test your responsive creation on an iPhone. You should at least bother to check it on several major platforms: iOS, Android (which has a swarm of different browsers), Windows Phone, Blackberry.

If you are tough enough, all the above is your absolute minimum, which you happily extend with everything that comes to hand.

The more you use the principle of progressive enhancement, proper fallbacks and unobtrusive javascript, the easier it is to test and fix the site on different devices, and the better the site will look on the devices you didn’t event bother to test on.

Briefly about desktop browsers


First things first, latest stable versions of Firefox, Chrome, Opera, IE, plus Opera 12 (on Presto), that’s all clear. After a year or so Presto engine will be gone for good :-(

The main problem, as usual, comes with IE. IE users are distributed almost evenly between three version of the browser. You can’t install several version of IE on the same system, different “IE testers” are all crap. Even if they work, they still don’t show native XP font rendering and form elements.

The solution here is to have a bunch of virtual machines. Grab VirtualBox, clone two winXP machines, give ’em 196 Mb of RAM and install latest IE7 and IE8. It’s, actually, a good time to send IE7 to the dump, but I keep it for rare ocasions, since some of my scripts support it and I need to test new builds once in a while.

Clone another two machines running Win 7 (give ’em 512 Mb of RAM) and install IE9 and IE10. All this stuff works simultaneously pretty effortlessly:


I still hope IE’s autoupdate (it was introduced in IE10) will make the difference some day and we won’t need to keep all this VMs. It’s not the case as of now.

Linux & Mac

It’s also worth having a VM with some linux distributive and, if possible, a Mac would also be good. Same browsers have significant differences when it comes to rendering system specific stuff, such as fonts, form elements and cursors.

Mobile devices

The main rule here: if it’s possible to test on a real device – test on a device. Here’s a couple of reasons:

My initial idea to buy a device working on each of the popular operating systems (iOS, Android, Windows Phone) realized and turned into gathering of rare devices with browser on board.

My collection now contains Kindle Keyboard and Kindle Paperwhite with their grayscale webkits, Nokia Asha 501 (a phone on modified S40 with horrible Ovi browser and not so horrible Opera Mini working on Java), Nintendo DSi bought after reading this article, Nintendo 3DS, PS Vita and lots of other rare and not so rare stuff.

The swarm
The swarm

It’s important to note, though, that any large project can’t be properly tested on all of them. The main goal here is not to support each and every device, but to properly optimize the site, make it adaptive in a flexible way. The site shouldn’t necessarily work equally on each device, but it’s important to ensure the availability of content and get rid of the nastiest bugs, possibly avoiding UA sniffing (although it’s hard at times).

The possibility to touch and test your project on different devices gives valuable information on the adequacy of the UI, availability of necessary fallbacks, typical bugs encountered on different devices, etc. All this allows you to create good universal development patterns and apply them in the future, reducing the need for testing to a minimum.

Where to test


Bonus pack in order of subjective importance:

For fun:

Where to get the emulators

Debugging on mobile devices


In the stock browser, type about:debug in the adress bar. This will lead to a new debug section appearing in the browser’s settings with a bunch of dev options in it, including concole.

In Android Chrome, you can use remote debugging:

Now you have full webkit devtools at your disposal. All the interactions are displayed on the device in real-time:

Changes are displayed in real-time


If you happen to have a Mac, you can debug an iOS device remotely via Safari’s web inspector:

Just like on Android, full devtools are available.


Blackberry has remote debugging via web-based webkit devtools:

Web-based webkit devtools work properly only in webkit-based browsers.

Remote debugging in Blackberry browser
Remote debugging in Blackberry browser


Great tool allowing you to remotely debug almost any device. All you need to do is to inject a script containing a unique ID (preferably before the rest of the scripts, so you won’t miss any logs and errors), and you got yourself a console with error output and remote command execution. Don’t forget to remove the script from production!

Read detailed official docs.

Your own console

If using jsconsole is inconvenient for some reason, you can always write your own console. Just redefine console.log, console.warn, console.error, window.onerror and something else to your taste. You’ll get a fairly simple tool which is sufficient in most cases.

Here’s a simple example:

var customConsole = {
    log: function(message) {
        this.add(message, 'info');
    warn: function(message) {
        this.add(message, 'warning');
    error: function(message, source, file) {
        this.add([message, source, file].join('<br>'), 'error');
    add: function(message, type) {
        if (typeof message !== 'string') message = '<i>' + message + '</i>';
        document.getElementById('console').innerHTML += '<p class=' + type + '>' + message + '</p>';

if (dev_console) {
    window.console = customConsole;
    window.onerror = function(message, source, file) {
        console.error(message, source, file);

Modify it to your own taste and needs.

Testing a website running on a local web server on mobile devices

The easiest way is to connect everithing to the same WiFi router. You should also set fixed IP adress for your computer, since it have a tendency to change unexpectadly and make all of your mobile bookmarks useless. Then use this very IP in your webserver’s config, e. g. enginx:

server {



That’s it, check out the site from your mobile devices.

If the web server is running on a virtual machine, make a bridge connection (in the VM’s settings). VM will get an IP in the routers subnet, use it to access the site both from mobile devices and from the host OS.

Testing in proxy browsers

That is Opera Mini. And Ovi, if you are desperate enough.

The problem with proxy browser is that you can’t test your site on a local server, since it should be visible on the internet.

My approach here is to create a test subdomain with http authentication on the hosting server and pull current version of the site using git once in a while. The site will be accessible by proxy browsers and remain password protected at the same time. An example config for http authentication (for Apache this time):

<VirtualHost *:80>

    <Location />
        Deny from all
        Allow from #YOUR IP HERE
        AuthUserFile /etc/apache2/users
        AuthName testdomain
        AuthType Basic
        Satisfy Any
        require valid-user


You can put your IP after Allow from to simplify the access to the domain from regular browsers.

You can read apache docs on adding user/password pairs to the http auth. Long story short, htpasswd -cm /etc/apache2/users username will ask you for the password, then create a file at the specified path and add a user username with MD5-encrypted password. Be careful, as the -c flag rewrites the existing file.


Test your sites on a maximum number of available devices and emulators. Use new HTML5 features and specific device capabilities, but don’t forget about proper fallbacks and broad content availability.

Published on