O que é Selenium Grid? Como funciona e exemplo com Docker

Selenium Grid

Também chamado de: Selenium Grid 4, grid do Selenium, Selenium Grid Docker

Definição

Servidor do Selenium que direciona sessões WebDriver para nós de navegador remotos, permitindo rodar testes em paralelo em vários navegadores, versões e máquinas.

O Selenium Grid permite que um teste crie o seu navegador em outro lugar. O teste usa o RemoteWebDriver e aponta para a URL do Grid; o Grid encontra um nó com um navegador compatível (por exemplo, Chrome no Linux), inicia uma sessão nele e repassa cada comando. Como muitos nós podem atender sessões ao mesmo tempo, o Grid é a forma clássica de rodar uma suíte Selenium em paralelo e em vários navegadores.

Exemplo

Suba um Grid em uma única máquina com a imagem Docker oficial:

docker run -d -p 4444:4444 --shm-size="2g" selenium/standalone-chrome

Depois conecte a partir de um teste (Selenium 4, Java 21):

ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(
    URI.create("http://localhost:4444").toURL(), options);

driver.get("https://example.com");

As opções do navegador são as “capabilities” que o Grid compara com os seus nós. A interface do Grid em http://localhost:4444 mostra os nós, os slots e as sessões em execução.

Como ele é estruturado (Grid 4)

O Selenium Grid 4 pode rodar em três modos:

Standalone: tudo em um único processo, bom para uso local e jobs de CI pequenos.
Hub e nós: um hub recebe as sessões e vários nós executam os navegadores. Inicie com java -jar selenium-server-<version>.jar hub e ... node.
Totalmente distribuído: os componentes internos do hub (Router, Distributor, Session Map, New Session Queue, Event Bus) rodam como processos separados, o que combina com Kubernetes.

O Grid 4 também deixou de exigir o antigo caminho /wd/hub, embora ainda o aceite.

Erros comuns

Esperar que o Grid deixe os testes paralelos. O Grid fornece navegadores. O seu test runner (JUnit 5, TestNG) ainda precisa ser configurado para rodar testes de forma concorrente, e os testes precisam ser isolados.
Mais threads do que slots. Pedidos extras de sessão entram na fila e podem dar timeout. Ajuste o paralelismo do runner aos slots disponíveis.
Não encerrar os drivers. Um driver.quit() esquecido deixa sessões ocupando slots até expirarem.
Memória compartilhada pequena no Docker. O Chrome trava com o /dev/shm padrão do container, daí a flag --shm-size.

Serviços de nuvem hospedados expõem o mesmo endpoint WebDriver de um Grid, então o código com RemoteWebDriver é idêntico; só mudam a URL e as capabilities.