Browser headless

Un browser headless carica le pagine, esegue JavaScript, costruisce il DOM e gestisce le richieste di rete esattamente come un browser normale, ma non disegna nulla sullo schermo. I test lo pilotano tramite lo stesso protocollo di automazione di un browser con interfaccia grafica (headed). Poiché non richiede un display server, è il modo predefinito per eseguire i test di UI nei container di CI e sugli agent di build.

Esempio

Playwright gira in modalità headless per default. Puoi scegliere di mostrare una finestra quando fai debug:

npx playwright test            # headless
npx playwright test --headed   # show the browser
npx playwright test --ui       # interactive UI mode

In Selenium 4 richiedi la modalità headless tramite le opzioni del browser:

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new");
WebDriver driver = new ChromeDriver(options);

FirefoxOptions options = new FirefoxOptions();
options.addArguments("-headless");
WebDriver driver = new FirefoxDriver(options);

Perché è importante

• Gira ovunque. Gli agent di build e i container Docker di solito non hanno un display, quindi un’esecuzione headed richiederebbe un framebuffer virtuale.
• Usa meno risorse di un browser headed, quindi puoi eseguire più worker in parallelo sulla stessa macchina.
• È un vero browser. Le versioni headless moderne di Chrome e Firefox usano lo stesso motore di rendering delle versioni headed, ed è per questo che i test scritti in headless in genere si comportano allo stesso modo in headed.

Insidie comuni

• Differenze di viewport. Un browser headless può partire con una dimensione di finestra predefinita diversa da quella del tuo browser desktop. Imposta il viewport in modo esplicito, così che i layout responsive si comportino in modo coerente.
• “In headed funziona, in headless fallisce”. Di solito è un problema di tempistiche, non della modalità headless in sé: l’esecuzione headless è più veloce o più lenta e fa emergere un’attesa mancante. Cattura una trace o uno screenshot in caso di fallimento invece di passare la CI in headed.
• Fare debug alla cieca. Attiva screenshot, video o trace per i test falliti, così puoi vedere quello che ha visto il browser headless.
• Confondere headless con “non è un browser”. Gli strumenti che si limitano a scaricare l’HTML, senza eseguire JavaScript, non sono browser headless e non possono testare una moderna single-page app.