These days, headless browser has become very popular. There are some major browsers natively support headless mode such as Chrome headless, Firefox Headless. However , people still argue about should we use it or not.
So when should we use headless browsing for automation testing? Like Joe also mentioned in his post headless browser testing pros cons, it depends on your testing goals.
In my project, we both use headless and real browser for automation testing.
We use Chrome Headless for UI smoke suite which triggered when any Pull request merged and they are run on Docker which is a non-GUI environment.
We also use Chrome Headless for UI regression suite which triggered by nightly scheduler and also run on Docker.
And we aware that Chrome Headless is not a real browser, it is not what the real user will interact with the app, so when doing final regression on STAGE environment before release, we run all UI regression tests on real browser using cloud based Sauce Labs.
Basically, Chrome headless help us catch any bugs very fast early on TEST environment, in smoke test or nightly regression. And if any bug which could not be found by headless mode, we can catch it on real browser when running tests on Sauce Labs.
In this post, I also want to review what is Headless browser, What is Pros and cons when using it, as many people are using but not really understand it.
I. What is Headless Browser ?
A headless browser is a web browser without a graphical user interface. Headless browsers provide automated control of a web page in an environment similar to popular web browsers, but they are executed via a command-line interface or using network communication. They are particularly useful for testing web pages as they are able to render and understand HTML the same way a browser would, including styling elements such as page layout, color, font selection and execution of JavaScript and Ajax which are usually not available when using other testing methods.
https://en.wikipedia.org/wiki/Headless_browser
Normally, interaction with a website are done with mouse and keyboard with a GUI, While most headless browser provides an API to manipulate the page/DOM, download resources etc. So instead of, for example, actually clicking an element with the mouse, a headless browser allows you to click an element by code.
If you curious about its architecture , read this document Headless Chrome architecture
II. Benefits of Headless Browser
- Greater testing reach: allow to run UI tests on non-GUI environment like Docker, linux.
- Improved speed and performance: test run faster and consume less resources (CPU, memory)
- Multitasking: With the UI disabled, headless testing lets you continue to use your computer while the tests execute in the background.
III. Disadvantages Of Headless Browser
- Hard for debugging as you do not see what happen on the browser
- Not a real browser, not mimic the real user interactions
IV. What you may interest
- Default screen size of Chrome headless is 800×600, if your application want to address a specific screen size, you need to set the view port for the Chrome headless instance before running the test.
V. Debugging in headless mode
- When encountering an issue in headless mode, first action to debug would be running it on headful mode (UI) to see what happens.
- When debug on non-GUI environment which running headless mode, you can try to take screenshot on failure or debugging point to see what the Web page look like.
- Alternatively, You can print/log all the HTML source to see what element is in the DOM tree. example when using Selenium:
print(driver.execute_script("return document.body.outerHTML;")) - Be aware of User Agent of Headless mode. The headless traffic may be blocked by a bot detection/mechanism. it will look like this :
'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/90.0.4430.212 Safari/537.36'. If you encounter this issue, let’s try to overwrite the default User-Agent.
Reference Links:
Step Up Automation 