I thought I’d elaborate on my testing strategy that I introduced during a talk I gave recently for Typecast’s seminar series. I described how I use two different testing methods for typography and responsive layouts.

Both are two very different facets of the same overall system and subsequently require different test conditions. In essence, I test typography on devices and I test layout in the browser.

Mobile devices aren’t great for layout testing

Device stands may look pretty on your desk, but they’re not going to cover all the possible states of a responsive layout. In fact, testing layouts purely on a set of devices is no different than designing for a set of predefined weights and heights — devices let you see how a layout will act at a particular size, but that’s the only size you’ll see on that screen¹.

This is why I do the majority of my layout testing in the browser. A browser will let you see all the in-between states that a set of devices won’t let you see. Expanding and collapsing the browser window from the small compressed state to an uncompressed wide state like an accordion allows you to see your elements actively respond and helps identify any potential gaps or problem areas.

Of course the actual device will show you the definitive state for that particular device - but what about every other permutation of the responsive layout?

The desktop browser helps paint the complete layout picture. No modern mobile browser gets the basic fundamentals of CSS layout so wrong that it requires you to refresh and investigate every layout change[^1].

Desktop browsers aren’t great for testing type

Where a desktop browser excels at showing you the difference in screen sizes, shapes and dimensions - it fails to account for the potential differences in type rendering between browsers and operating systems. A single browser window can only show you how type renders for that individual display and configuration.

The vast array of different mobile device displays requires a testing setup that caters for the variance in different screen densities, resolutions and screen types to give an indication of how type renders in these different environments.

An electronic ink display might render the type blurry compared to the display of a crisp high density screen. This is where a broad set of devices comes in handy - it pays to stress test your fonts across the often unforgiving and varied display properties of mobile devices. A single desktop browser won’t let you know about any of these potential issues.

The best of both worlds

I still reference mobile browsers during layout testing from time to time - functional testing is a different matter where I test heavily on all devices - but primarily my layout testing happens in the browser and my type testing happens on mobile displays.

The speed and efficiency of scaling a desktop browser window from small to large for building truly responsive layouts met with a set of devices that represent as much of the potential difference in display types is the sweet spot that works for me.