Glossario · Automazione della UI
Selenium Grid
Detto anche: Selenium Grid 4, griglia Selenium
Definizione
Server Selenium che instrada le sessioni WebDriver verso nodi browser remoti, così i test possono girare in parallelo su molti browser, versioni e macchine.
Selenium Grid permette a un test di creare il proprio browser altrove. Il test usa RemoteWebDriver e lo punta all’URL della Grid; la Grid trova un nodo con un browser corrispondente (ad esempio Chrome su Linux), vi avvia una sessione e inoltra ogni comando. Poiché molti nodi possono servire sessioni contemporaneamente, la Grid è il modo classico per eseguire una suite Selenium in parallelo e su più browser.
Esempio
Avvia una Grid su una singola macchina con l’immagine Docker ufficiale:
docker run -d -p 4444:4444 --shm-size="2g" selenium/standalone-chrome
Poi collegati da un test (Selenium 4, Java 21):
ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(
URI.create("http://localhost:4444").toURL(), options);
driver.get("https://example.com");
Le opzioni del browser sono le “capabilities” che la Grid confronta con i suoi nodi. La UI della Grid su http://localhost:4444 mostra nodi, slot e sessioni in esecuzione.
Com’è strutturata (Grid 4)
Selenium Grid 4 può funzionare in tre modalità:
- Standalone: tutto in un unico processo, adatto all’uso locale e a piccoli job di CI.
- Hub e nodi: un hub riceve le sessioni e diversi nodi eseguono i browser. Si avvia con
java -jar selenium-server-<version>.jar hube... node. - Completamente distribuita: i componenti interni dell’hub (Router, Distributor, Session Map, New Session Queue, Event Bus) girano come processi separati, una soluzione adatta a Kubernetes.
La Grid 4 ha anche eliminato la necessità del vecchio percorso /wd/hub, anche se continua ad accettarlo.
Errori comuni
- Aspettarsi che la Grid renda i test paralleli. La Grid fornisce i browser. Il tuo test runner (JUnit 5, TestNG) deve comunque essere configurato per eseguire i test in modo concorrente, e i test devono essere isolati.
- Più thread che slot. Le richieste di sessione in eccesso finiscono in coda e possono andare in timeout. Allinea il parallelismo del runner agli slot disponibili.
- Non chiudere i driver. Un
driver.quit()mancante lascia sessioni che occupano slot finché non scadono. - Shared memory troppo piccola in Docker. Chrome va in crash con la
/dev/shmpredefinita del container, da qui il flag--shm-size.
I servizi cloud in hosting espongono lo stesso endpoint WebDriver di una Grid, quindi il codice con RemoteWebDriver è identico; cambiano solo l’URL e le capabilities.