Automação de Testes utilizando Selenium

O Selenium é, há mais de duas décadas, uma das ferramentas mais usadas para automação de testes de aplicações web. Ele controla o navegador como um usuário real, o que permite validar fluxos completos de ponta a ponta. Com o Selenium 4, a ferramenta ganhou um protocolo padronizado, gerenciamento automático de drivers e novos recursos que tornam a escrita de testes mais simples e estável.

Este guia é prático e técnico. Vamos do ambiente ao primeiro teste com JUnit 5, passando por esperas, localizadores, a arquitetura Page Object Model (POM), integração com Cucumber e uma olhada no futuro com o Vibium. Os exemplos usam Selenium 4 e Java.

O que é o Selenium?

O Selenium não é uma ferramenta única, e sim um conjunto. Os três principais componentes são o WebDriver, que controla o navegador via código; o Selenium IDE, uma extensão para gravar e reproduzir testes de forma rápida; e o Selenium Grid, que distribui a execução em paralelo por várias máquinas e navegadores. Na automação séria, o WebDriver é o protagonista.

O que mudou no Selenium 4

Se você aprendeu Selenium anos atrás, vale conhecer o que mudou, porque parte do conteúdo antigo na internet ficou obsoleto:

• Protocolo W3C WebDriver: a comunicação com o navegador passou a seguir o padrão W3C, o que deixou os testes mais estáveis entre navegadores.
• Selenium Manager: o Selenium baixa e configura o driver do navegador automaticamente. Não é mais preciso baixar o chromedriver manualmente nem usar bibliotecas externas para isso.
• Relative locators: novos localizadores que encontram elementos pela posição relativa a outros (acima, abaixo, à esquerda, à direita ou próximo).
• Nova API de janelas e abas: abrir uma aba ou janela ficou direto, com driver.switchTo().newWindow().
• WebDriver BiDi: um protocolo bidirecional que abre caminho para interceptar rede, capturar logs do console e cenários mais avançados.

Preparando o ambiente

Aqui vai a primeira boa notícia: você não precisa baixar uma IDE específica nem o driver do navegador manualmente. Qualquer editor moderno serve, e o Selenium Manager cuida do driver. Em um projeto Java com Maven, basta adicionar as dependências do Selenium e do JUnit 5:

<!-- pom.xml -->
<dependencies>
  <dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version>4.27.0</version>
  </dependency>
  <dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>5.11.3</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Use sempre a versão mais recente disponível. Com isso, o ambiente já está pronto para o primeiro teste.

Primeiro teste com Selenium 4 e JUnit 5

O exemplo abaixo automatiza um login e valida o redirecionamento. Note o uso de @BeforeEach e @AfterEach para abrir e fechar o navegador a cada teste, mantendo o isolamento:

import org.junit.jupiter.api.*;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import static org.junit.jupiter.api.Assertions.assertTrue;

class LoginTest {

    WebDriver driver;

    @BeforeEach
    void setUp() {
        // Selenium Manager baixa e configura o driver automaticamente
        driver = new ChromeDriver();
        driver.manage().window().maximize();
    }

    @Test
    void deveAutenticarComCredenciaisValidas() {
        driver.get("https://exemplo.com/login");
        driver.findElement(By.id("email")).sendKeys("user@exemplo.com");
        driver.findElement(By.id("senha")).sendKeys("senha123");
        driver.findElement(By.cssSelector("button[type=submit]")).click();

        assertTrue(driver.getCurrentUrl().contains("/dashboard"));
    }

    @AfterEach
    void tearDown() {
        driver.quit();
    }
}

Esperas: o segredo contra testes instáveis

A maior causa de testes instáveis (flaky) é interagir com um elemento antes de ele estar pronto. Evite Thread.sleep com tempo fixo e prefira esperas explícitas, que aguardam por uma condição específica:

import java.time.Duration;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.openqa.selenium.support.ui.ExpectedConditions;

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.elementToBeClickable(By.id("entrar"))).click();

Localizadores e os novos relative locators

Além dos localizadores clássicos (By.id, By.cssSelector, By.xpath), o Selenium 4 traz os relative locators, que encontram elementos pela posição em relação a outros. Eles são úteis quando a estrutura do HTML é instável, mas a disposição visual é previsível:

import static org.openqa.selenium.support.locators.RelativeLocator.with;

// Encontra o campo de senha que fica logo abaixo do campo de e-mail
WebElement senha = driver.findElement(
    with(By.tagName("input")).below(By.id("email")));

Organizando os testes com Page Object Model (POM)

Escrever localizadores espalhados pelos testes vira um pesadelo de manutenção. O Page Object Model resolve isso ao representar cada página como uma classe que concentra seus elementos e ações. Quando a interface muda, o ajuste acontece em um único lugar. É uma das práticas mais importantes para uma suíte sustentável, tema que aprofundamos no artigo sobre frameworks de automação.

Primeiro, a página de login como um Page Object:

public class LoginPage {

    private final WebDriver driver;
    private final By email = By.id("email");
    private final By senha = By.id("senha");
    private final By entrar = By.cssSelector("button[type=submit]");

    public LoginPage(WebDriver driver) {
        this.driver = driver;
    }

    public DashboardPage autenticar(String usuario, String password) {
        driver.findElement(email).sendKeys(usuario);
        driver.findElement(senha).sendKeys(password);
        driver.findElement(entrar).click();
        return new DashboardPage(driver);
    }
}

Agora o teste fica limpo, legível e focado no comportamento, sem detalhes de localizadores:

@Test
void loginValidoLevaAoDashboard() {
    driver.get("https://exemplo.com/login");

    DashboardPage dashboard = new LoginPage(driver)
        .autenticar("user@exemplo.com", "senha123");

    assertTrue(dashboard.estaVisivel());
}

Selenium com Cucumber (BDD)

Um ponto forte do Selenium é a flexibilidade: ele se encaixa tanto com frameworks de teste como o JUnit 5 quanto com abordagens de BDD como o Cucumber. No BDD, o cenário é descrito em linguagem próxima da natural, no formato Dado-Quando-Então, aproximando time técnico e negócio. Veja o mesmo login descrito em um arquivo de funcionalidade:

# login.feature
Funcionalidade: Login
  Cenário: Login com credenciais válidas
    Dado que estou na página de login
    Quando informo um usuário e senha válidos
    Então devo ser redirecionado para o dashboard

As etapas (steps) ligam cada frase ao código Selenium. Repare que o mesmo Page Object é reaproveitado, mostrando como POM, Selenium e Cucumber convivem bem:

import io.cucumber.java.pt.*;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class LoginSteps {

    WebDriver driver = new ChromeDriver();
    LoginPage login = new LoginPage(driver);

    @Dado("que estou na página de login")
    public void abrirLogin() {
        driver.get("https://exemplo.com/login");
    }

    @Quando("informo um usuário e senha válidos")
    public void informarCredenciais() {
        login.autenticar("user@exemplo.com", "senha123");
    }

    @Então("devo ser redirecionado para o dashboard")
    public void validarDashboard() {
        assertTrue(driver.getCurrentUrl().contains("/dashboard"));
    }
}

Boas práticas com Selenium

• Adote o Page Object Model desde o início para isolar a interface da lógica dos testes.
• Use esperas explícitas e evite tempos fixos de espera.
• Mantenha os dados de teste isolados e priorize cenários por risco, como em testes de regressão.
• Integre a suíte ao pipeline de CI/CD para rodar a cada entrega.
• Escale a execução em paralelo com o Selenium Grid quando a suíte crescer.
• Atenção a práticas que sabotam os resultados, como detalhamos em boas práticas de automação.

O futuro: do Selenium ao Vibium

Vale ficar de olho no que vem por aí. Jason Huggins, criador do Selenium, está desenvolvendo o Vibium, apresentado como um sucessor pensado para a era da IA. A proposta nasce de uma pergunta direta: se fôssemos refazer o Selenium para que ele deixasse de ser instável, o que mudaríamos? A resposta passa por comunicação via WebSocket e WebDriver BiDi, além de recursos como descrição de testes em linguagem natural e self-healing de seletores quebrados.

O Vibium ainda está em estágio inicial, mas sinaliza para onde a automação caminha. Conhecer bem o Selenium hoje é a melhor base para acompanhar essa evolução sem sustos.

Conclusão

O Selenium 4 está mais simples e estável do que as versões que popularizaram a ferramenta. Com Selenium Manager, relative locators e o protocolo W3C, escrever testes ficou mais direto, e, combinado a boas práticas como o Page Object Model, a JUnit 5 e ao Cucumber, ele atende desde times técnicos até cenários de BDD. Para escolher a ferramenta certa para o seu contexto, vale comparar as opções no nosso guia de frameworks de automação de testes.

Vale destacar que o Proton, a plataforma de automação da Atomic, oferece suporte ao Selenium. Isso permite integrar e orquestrar as automações construídas com essa tecnologia em um único lugar, somando o poder do Selenium à gestão centralizada da plataforma.

Quer implementar automação de testes com a segurança de quem tem 10 anos de mercado e expertise em Quality Assurance? Fale com a Atomic Solutions e acelere suas entregas sem abrir mão da qualidade.