paint-brush
How I built a Headless Testing Serviceby@headlesstesting
115 reads

How I built a Headless Testing Service

by Jochen DelabieMarch 6th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Headless Testing is built mainly with NodeJS. Central component receives new Headless sessions from Puppeteer or Playwright scripts and forwards it to a Virtual Machine or Container. The VM or Container runs another NodeJS service that receives the request and sets up the browser to do headless testing. Each test runs on a pristine environment and is destroyed after each session, ensuring maximum privacy. Next steps are adding support for more browsers, adding more features and generally improving performance. The service is only the start.

Company Mentioned

Mention Thumbnail
featured image - How I built a Headless Testing Service
Jochen Delabie HackerNoon profile picture

As a solo developer I've been working hard at building a new service called Headless Testing

There's a couple of reasons why I built this new service:

  • it's fun to build: there's some challenging problems to solve
  • it builds on fundaments that I've previously built with TestingBot.com (Online Selenium Cloud)
  • the technology behind Headless Testing is pretty new to me, and I'm eager to learn

The service is built mainly with NodeJS. There's a central component that receives new Headless sessions from Puppeteer or Playwright scripts and forwards it to a Virtual Machine or Container.

The VM or Container runs another NodeJS service that receives the request and sets up the browser to do headless testing. In case of Chrome, this happens with setting these startup flags:

--headless --remote-debugging-port=9222

Chrome will start without a UI (Headless Mode). We then fetch the WebSocket details from Chrome to be able to connect to the Chrome DevTools service and start proxying everything to the user.

Once Puppeteer or Playwright have the WebSocket address, they start sending Chrome DevTools commands to the browser, automating the browser.

We make sure the VMs and Containers run optimally (assign enough RAM and CPU for the browser). Each test runs on a pristine environment and is destroyed after each session, ensuring maximum privacy.

Future Steps

This is only the start. Next steps are adding support for more browsers, add more features and generally improve performance.