Selenium para Teste de API: É Possível e Vale a Pena?

Selenium é um framework de automação de navegadores. Ele controla o Chrome, Firefox e outros navegadores da mesma forma que uma pessoa faria: clicando em botões, preenchendo formulários, lendo a página renderizada. É a ferramenta padrão para testes de UI de ponta a ponta, e é muito bom nesse trabalho.

As pessoas ainda perguntam se o Selenium pode testar APIs. A resposta honesta é que você pode fazer com que ele emita chamadas HTTP, mas é a ferramenta errada para o trabalho. Este guia explica exatamente o porquê, mostra como realmente é o teste de API através do Selenium e aponta ferramentas que são construídas para essa finalidade. O objetivo é poupar você de uma configuração que o frustrará mais tarde.

Por que Selenium e testes de API não combinam

Um teste de API envia uma requisição HTTP diretamente para um servidor e verifica a resposta: código de status, cabeçalhos, corpo, tempo. Não há interface de usuário envolvida. O teste deve ser rápido, isolado e barato para ser executado milhares de vezes.

Selenium faz o oposto por design. Ele inicia um navegador real, carrega páginas e espera o JavaScript renderizar. Esse navegador é o ponto principal quando você está testando uma UI, e é pura sobrecarga quando você está testando uma API. Uma requisição que um cliente dedicado envia em dezenas de milissegundos torna-se um processo de vários segundos assim que você envolve um processo de navegador, uma sessão do WebDriver e a renderização da página.

Há também uma incompatibilidade mais profunda. Toda a API do Selenium é sobre elementos em uma página: encontrar este botão, ler este texto, esperar por este elemento. Uma resposta HTTP não é uma página. Ela não tem DOM. Portanto, o Selenium não oferece nada útil para inspecionar um corpo JSON, fazer asserções em um cabeçalho ou verificar um código de status. Você acaba contornando a ferramenta em vez de trabalhar com ela.

O custo não é apenas a velocidade. Testes baseados em navegador são notoriamente instáveis (flaky). Eles falham porque uma página demorou um pouco mais para renderizar, porque uma sessão do WebDriver caiu, ou porque uma atualização do navegador alterou algum tempo. Um teste de API deve ser determinístico: a mesma requisição produz a mesma resposta, e uma falha significa que algo realmente quebrou. Roteando verificações de API através do Selenium importa toda essa instabilidade do navegador para uma camada que não tem razão para ser instável. Com o tempo, uma suíte instável treina a equipe a ignorar builds vermelhos, o que anula o objetivo do teste. A distinção entre validação e verificação é uma boa perspectiva aqui: Selenium verifica a experiência renderizada, enquanto o teste de API valida o contrato subjacente.

O que "testar API com Selenium" realmente significa

Quando artigos afirmam que o Selenium pode testar APIs, eles geralmente se referem a uma de duas soluções alternativas. Nenhuma delas torna o Selenium uma ferramenta de teste de API. Elas apenas roteiam o HTTP através ou ao lado dele.

Opção um: usar o executor de JavaScript do Selenium. Selenium pode executar JavaScript arbitrário no navegador que ele controla. Navegadores modernos possuem a API fetch, então você pode pedir ao navegador para fazer uma requisição e retornar o resultado para o seu código de teste:

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

Isso funciona. Também significa que você iniciou um navegador, um WebDriver e uma ponte JavaScript puramente para fazer uma chamada HTTP que um cliente HTTP normal faria diretamente. Você também herda restrições do navegador como o CORS, sobre as quais um teste de API de servidor para servidor nunca precisa se preocupar.

Opção dois: ignorar o Selenium e usar uma biblioteca HTTP real ao lado dele. Em um projeto Java, isso significa emparelhar o Selenium com o REST Assured para as partes da API:

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

Note que o teste de API real aqui é feito inteiramente pelo REST Assured. O Selenium não contribui em nada. As duas bibliotecas simplesmente coexistem no mesmo projeto. Isso é aceitável, mas não é "teste de API com Selenium". É teste de API com uma biblioteca de teste de API adequada, com o Selenium presente para testes de UI não relacionados.

Quando misturá-los é razoável

Há um caso legítimo para o trabalho HTTP dentro de uma suíte de Selenium, e vale a pena ser claro sobre isso. Testes de UI com Selenium frequentemente precisam de configurações (setup) ou desconstruções (teardown) que são mais rápidas de fazer via API do que através do navegador.

Digamos que você tenha um teste de UI que verifica a página de histórico de pedidos. Para testá-la, um pedido precisa existir. Clicar por todo o fluxo de checkout no navegador apenas para criar esse pedido é lento e frágil. Em vez disso, seu teste faz uma chamada direta à API para criar o pedido, e então usa o Selenium apenas para a parte que realmente precisa de um navegador: carregar a página de histórico e verificar se o pedido aparece.

Essa é uma prática sólida. A chamada de API é um meio para um fim, não o objeto de teste. A chamada de API ainda deve passar por um cliente HTTP real, e não pelo executor de JavaScript. Portanto, mesmo neste caso, o Selenium não está realizando o teste de API. Ele está realizando o teste de UI, e um cliente HTTP adequado lida com o lado da API.

Este padrão de configuração via API é comum o suficiente para que a maioria das suítes de teste maduras o adote deliberadamente. Ele mantém a parte lenta e baseada em navegador da suíte o menor possível, reservada para as poucas jornadas que realmente precisam de uma página renderizada. Todo o resto, incluindo toda a preparação de dados e a maior parte da verificação, acontece por meio de chamadas HTTP rápidas. O resultado é uma suíte que é executada em minutos em vez de horas e falha por razões reais. Para uma visão mais ampla de como as camadas de UI e automatizadas se encaixam, veja teste funcional versus teste automatizado.

Use uma ferramenta construída para testes de API

Se o seu objetivo é testar APIs, use algo projetado para isso. A diferença não é pequena. Uma ferramenta de teste de API real oferece construção de requisições, gerenciamento de ambiente, asserções sobre status, cabeçalhos e corpo, encadeamento de requisições, execuções baseadas em dados e integração com CI, sem iniciar um navegador.

Suas opções se enquadram em alguns grupos:

Se você prefere código, uma biblioteca HTTP como REST Assured em Java, requests em Python ou supertest em Node é a escolha certa. Essas bibliotecas fazem uma requisição e retornam a resposta diretamente, com helpers de asserção construídos para códigos de status e corpos JSON. Não há navegador, WebDriver nem renderização, então uma suíte completa é executada rapidamente e falha apenas quando a própria API muda.

Se você deseja um espaço de trabalho visual, Apidog é uma plataforma de API completa que abrange o design da API, depuração de requisições, simulação de endpoints, construção de cenários de teste automatizados e geração de documentação, tudo em um único projeto. Você constrói asserções visualmente ou com scripts, encadeia requisições em fluxos de várias etapas, executa iterações baseadas em dados e tudo é executado em CI. Ele também importa arquivos OpenAPI e Postman, então uma API existente é rapidamente integrada. Nada disso envolve um navegador, porque nada disso deveria. Você pode baixar o Apidog para testá-lo contra uma API real.

Para equipes que desejam um framework code-first, os guias sobre Robot Framework para automação de API e construindo um framework de teste de automação de API abordam abordagens que, ao contrário do Selenium, são realmente adequadas para testes HTTP.

A conclusão honesta

Selenium é um software excelente para o que foi construído para fazer, que é automatizar navegadores. Testes de API não são isso. Você pode tecnicamente enviar HTTP através do executor de JavaScript do Selenium, e pode manter uma biblioteca HTTP no mesmo projeto que o Selenium, mas em nenhum dos casos o Selenium está agregando valor ao próprio teste de API.

Escolher a ferramenta errada não é uma decisão neutra. Isso torna seus testes mais lentos, mais difíceis de manter e propensos a falhas que nada têm a ver com sua API. Procure por uma ferramenta construída para a tarefa. Sua suíte de testes será mais rápida, mais confiável e muito mais fácil de entender. A lista das melhores plataformas de teste automatizado é um bom lugar para comparar opções construídas para um propósito específico.

Perguntas frequentes

O Selenium pode testar APIs REST?

Ele pode emitir requisições HTTP através do executor de JavaScript do navegador, então em um sentido técnico restrito, sim. Mas o Selenium não possui recursos para inspecionar respostas, fazer asserções em JSON ou verificar cabeçalhos, e carrega toda a sobrecarga de um navegador. Não é uma ferramenta de teste de API REST, e usá-lo como tal cria testes lentos e frágeis.

Por que alguns tutoriais mostram Selenium com REST Assured?

Porque o teste de API nesses tutoriais é feito inteiramente pelo REST Assured, que é uma verdadeira biblioteca de teste HTTP. O Selenium está apenas presente no mesmo projeto para testes de UI não relacionados. A combinação é aceitável, mas não significa que o Selenium esteja testando a API. O REST Assured está.

É aceitável fazer chamadas de API em um teste de Selenium?

Sim, para setup e teardown. Criar dados de teste via API é mais rápido e confiável do que clicar na UI para produzi-los. A chamada de API apoia o teste de UI em vez de ser o objeto de teste, e ainda deve usar um cliente HTTP adequado, e não o executor de JavaScript do Selenium.

O que devo usar em vez de Selenium para testes de API?

Para testes code-first, uma biblioteca HTTP como REST Assured, requests do Python ou supertest para Node. Para um espaço de trabalho visual, uma plataforma de API dedicada como Apidog, ou clientes como Postman, Insomnia e Talend API Tester. Todos estes são construídos para HTTP e evitam a sobrecarga do navegador imposta pelo Selenium.

Usar Selenium para testes de API atrasa meu pipeline de CI?

Significativamente. Cada chamada de API baseada em Selenium inicia um processo de navegador e uma sessão do WebDriver, transformando uma requisição HTTP de sub-segundo em uma operação de vários segundos. Ao longo de uma suíte, isso se soma a execuções de pipeline longas e instáveis. Uma ferramenta dedicada de teste de API executa as mesmas verificações muito mais rapidamente porque nunca inicia um navegador.