Headless Browser Testing 101
If you’re a QA engineer, you probably use headless browser testing all the time—with good reason. If you don’t, you may be missing out on many testing benefits.
To help identify what those benefits are, this article explains what headless browser testing is and which use cases it supports. It also identifies the limitations of headless browser testing, and discusses situations in which you may not want to use it.
What Is a Headless Browser?
“Headless browser” is a funny-sounding term that refers to something that software test engineers use all the time: a web browser that is not configured with a Graphical User Interface.
A headless browser is a type of software that can access webpages but does not show them to the user and can pipe the content of the webpages to another program. Unlike a normal browser, nothing will appear on the screen when you start up a headless browser, since the programs run at the backend.
Google Chrome and Firefox both have versions of their web browser with a headless option. Other browser options that offer some form of a headless implementation include: PhantomJS, HtmlUnit, TrifleJS, Splash, and SimpleBrowser.
Headless browsers may not be very useful for surfing the Web, but they are a great tool for testing. Here are some things you might want to know about headless browser testing and the advantages and disadvantages of leveraging it for your testing needs.
Headless Browser Testing: How Can It Be Useful?
A full instance of a browser would be overkill if you just want to perform website scraping and data extraction. You may not necessarily want to start up a website, go to it, and scrape it. It is much easier and quicker to navigate to a website headlessly, scrape for data, and use the results to test multiple webpages as part of a quality control effort.
Headless browsers are your friend if performance is critical. They are faster than real browsers since they do not come with all the overhead of starting up a browser GUI, and this equates to quicker results for your tests. For your developers, this means a lot of time saved when they just want to perform quick and small smoke tests where the UI is irrelevant (i.e., “Can I log into the application?” or “Is SSL enabled?”). Being able to perform non-exhaustive tasks via the command line without the need to manually refresh a page or start a browser can save a lot of effort. Keep in mind that the overall performance still depends on the actual tests and the system being tested.
Here are some other use cases that can be leveraged with headless browser testing:
- Running tests on machines without a Graphical User Interface
- Generating screenshots and PDFs of webpages
- Monitoring network application performance
- Capturing a timeline trace of a website for performance diagnosis
- Simulating multiple browsers on a single machine without the resource hog
Limitations of Headless Browser Testing
As illustrated above, many things that can be tested manually in a real browser can be tested using a headless implementation, but you cannot actually use it for all your browser testing needs, and you should perform testing on real browsers most of the time.
At the end of the day, your end users are not using a headless browser, and so you do not want to focus on bugs that only happen in headless mode. In order to test for user experience and do a functional test, you need to mimic a real user and get precise feedback on what they will actually experience on the website. You want to observe the actual behavior and interaction between an end user and the browser.
Sometimes it is necessary to see your test run on a real browser. This can often be an easy and good debugging technique. If you need to do a lot of browser debugging, this can be challenging in headless mode. A headless browser is a different browser, and tests can catch bugs and throw errors that won’t occur on a real browser.
Automated headless browser testing is a great tool for testing software quickly across a range of environments. While headless testing has some limitations and can’t be used for every scenario, it will cover the majority of your software testing needs. And when paired with a test automation solution and cloud-based test grid, the ability of headless testing to scale is virtually unlimited.
Daisy Tsang is a Software Developer currently based in Berlin. She has worked at companies in Canada and Germany in the past few years, loves learning about new technologies, and is particularly interested in the open-source space. Her non-technical interests include photography, knitting, baking, and learning new natural languages.
- Accessibility Testing
- Appium Resources
- Best Practices
- Continuous Delivery
- Continuous Integration
- Continuous Testing
- Cross Browser Testing
- Guest Blog Posts
- Load Testing
- Machine Learning
- Mobile Development & Testing
- News & Product Updates
- Open Sauce
- Open Source
- Performance Testing
- Product Updates
- Quality Assurance
- Quality Engineering
- Sauce Product Info
- Security Testing
- Selenium Resources
- Software Development & Testing
- The Story of Sauce