Four Reasons to Use Headless Testing

Under the right conditions, headless browser testing is a great way to speed test results while also reducing the infrastructure required to run tests. In this article, we will take a look at four reasons why you might consider using headless testing. Learn more about when (and when not to) use headless testing here.

A headless browser is simply a web browser without a graphical user interface. Common browsers such as Firefox and Chrome can be run in headless mode, and there are a variety of browsers and tools that are designed to be run without a head.

Why would you run a browser without a GUI (Graphical User Interface)? After all, isn't the main purpose of a browser to allow users to look at web pages?

It's true - browsers are designed to present the content of a website visually, by means of a GUI, but a GUI imposes overhead in terms of both time and resources. A headless browser allows you to make use of its non-graphic features and at the same time avoid the GUI's overhead. This can be particularly important when it comes to saving time, since the time required to render even a relatively simple web page can be significant.

There are a variety of ways that you can use a headless browser - scraping web pages, for example, or even statistical analysis of page and site content. More than anything else, however, a headless browser can be just the tool that you need in order to rapidly and efficiently test your site or web-based application for both functionality and performance. Headless browser testing is script-driven and easy to automate. For tests which do not specifically involve the GUI, use of a headless browser may significantly speed up and simplify the testing process.

When is a headless browser the best solution for your testing needs - and what makes headless testing the right choice? Consider the following:

A typical browser running with a graphic interface has a demanding job. Every time the user opens a new page, the browser must render the entire page, including layout, fonts, visual effects, embedded graphics and videos, and embedded content pulled from other sites, adjusting the size and position of individual graphic elements as it does so.

When you're browsing in an environment with a high-speed connection, a fast, responsive server, and a client system with plenty of resources, it's easy to forget that these processes take time. The truth, however, is that each page that's fully rendered does require a measurable amount of time, and in any process where you need to move through a large number of pages rapidly (such as automated testing), those increments of time can add up to a significant delay.

Servers, connections, and client systems aren't perfect, and it is still not entirely uncommon for the arrival of key graphic (and functional) elements in a page to be delayed. If the functionality for an element isn't available until the graphic elements associated with it have been fully rendered, the resulting slowdown can add even more delays to your test process.

With headless testing, you don't need to render anything (unless you want to specifically perform graphics-related operations, such as capturing GUI elements in the form of screenshots or PDFs). This allows you to perform non-GUI tests without any of the delays associated with page rendering, speeding up and simplifying your test regime.

You can, for example, test functional elements such as buttons, forms, links, etc., along with their associated code without rendering them graphically. You can also test for non-graphic performance (SSL, front- and backend code), load management, and response time, as well as issues such as error handling, site architecture, and access to remote resources.

Headless browsers are also ideal for testing features at a relatively early stage of development, before their associated GUI components are fully in place. This allows you to test for functional and performance problems without having to wait for the visual elements of the page to be put in place.

Since functional/performance issues can impact page design, early testing of this kind can reduce potentially costly and time-consuming redesign. Early testing can also uncover problems which may affect site architecture, revealing potential bottlenecks, inefficient user flow, and data management issues. By using headless testing at the earliest possible stage, you can identify and implement the necessary architecture changes at a point where they are likely to have the least impact on other aspects of site development.

While it's true that most full-featured browsers can be run from the command line, headless browsers are by nature fully scriptable; any task which you can perform with a headless browser can be done from the CLI or a script, making them in effect optimized for automation.

This, combined with the advantages of speed, makes headless browsers ideal for high-volume automated testing. You can script a large and complex set of test regimes made up of commands which are unlikely to introduce unwanted interruptions based on such things as an unanticipated wait for a GUI interaction.

You can use automated headless browser testing of this sort in situations which require a very large number of repeated actions, such as stress and load testing. You can also use automation to run standard functional tests on code at an early point in the development cycle, catching errors which may have been introduced into existing features during an upgrade, for example.

It's no secret that most browsers are somewhat resource-intensive. Each window or tab can take up hundreds of megabytes of memory, not to mention a significant chunk of the processor's resources. Much of this overhead is the result of the demands placed on the system by the GUI. Not surprisingly, a headless browser typically operates with considerably less overhead, making it easier to run on a system with minimal resources.

You can use low-resource containers or VMs for headless browser testing, running automated tests in a cloud environment. This low demand for resources makes it possible to maximize the speed, variety, and volume of your tests. You can also use a minimal physical machine (for example, an older system with no monitor attached) to run automated tests in the production environment, freeing up newer hardware for more resource-intensive tasks.

Headless browsers don't require you to reinvent the wheel when it comes to testing. Sauce Labs, for example, offers Sauce Headless, a platform designed specifically for cloud-based testing using the headless versions of Chrome and Firefox. This allows you to integrate early-pipeline headless tests with later cross-browser testing, all within Sauce's rich and full-featured testing and analytics framework.

Headless testing isn't the universal testing solution, of course. If you want to visually test page rendering, test user interaction with the GUI, or test multimedia features, for example, you will need to use a browser with full graphics capabilities. You will probably also need to use a full browser for such things as testing user experience and for debugging.

You can separate your testing tasks into those which do require a full browser and those for which a headless browser will work, and then design your test regime accordingly. Doing this will allow you to make efficient use of your testing resources, maximize the number and variety of tests that you can run, and optimize your use of the time available for testing.

Michael Churchman started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the 90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time, he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues. He is a regular Fixate.io contributor.