Escrever um script de teste automatizado é fácil. Escrever um que ainda justifique seu lugar seis meses depois é a parte difícil. Muitos scripts de teste são escritos, rodam verdes uma vez e depois apodrecem silenciosamente, quebrando em mudanças não relacionadas, não afirmando nada significativo e treinando a equipe a ignorar builds que falham. Um bom script de teste é preciso, isolado e durável.
Este guia aborda o que é um script de teste automatizado, a estrutura que o torna confiável, duas maneiras de escrever scripts de teste de API e uma construção passo a passo no Apidog.
O que é um script de teste automatizado
Um script de teste automatizado é um conjunto definido e repetível de instruções que exercita parte do seu software e verifica o resultado, sem a necessidade de um humano executar os passos. O script envia uma entrada, executa uma ação e compara o resultado com uma expectativa. Se eles corresponderem, ele passa. Caso contrário, ele falha e relata o motivo.
Um script de teste é a forma executável de um caso de teste. O caso de teste descreve a intenção, a entrada, a ação e o resultado esperado, em termos humanos. O script transforma essa intenção em algo que uma máquina executa a cada commit. Um caso de teste pode se tornar um script; um cenário de teste geralmente se torna vários encadeados.
Todo o valor de um script de teste automatizado reside no fato de que ele roda da mesma maneira todas as vezes. Isso só é válido se o script for escrito para ser determinístico. Um script que depende da ordem em que outros scripts foram executados, ou de dados deixados por uma execução anterior, não é uma automação confiável; é uma falha intermitente e um passivo.
A estrutura de um script de teste confiável
Quase todo script de teste bem escrito, em qualquer linguagem ou ferramenta, segue a mesma forma de quatro partes. É frequentemente chamado de Organizar-Agir-Verificar (Arrange-Act-Assert), com a limpeza adicionada.
Organizar (Arrange). Configure tudo o que o teste precisa: os dados de entrada, autenticação, quaisquer pré-condições. O script deve criar seu próprio estado, em vez de assumir que ele existe. Se o teste precisar de um usuário, ele o cria, ou usa um fixture conhecido, não o que quer que esteja no banco de dados.
Agir (Act). Execute a única ação em teste. Um bom script testa um comportamento. Enviar uma requisição, chamar uma função, acionar um evento, isso é o ato, e deve haver exatamente um por script.
Verificar (Assert). Verifique o resultado em relação às expectativas. Esta é a parte em que as equipes menos investem. Um script que apenas afirma “nenhum erro foi lançado” ou “status era 200” mal testa alguma coisa. Asserções fortes verificam os valores reais: o corpo da resposta, o esquema, os efeitos colaterais, o tempo.
Limpeza (Cleanup). Desfaça o que o script criou para que possa ser executado novamente a partir de um estado limpo. Um script que deixa dados de teste para trás eventualmente colidirá consigo mesmo ou com outro script.
Três hábitos separam scripts duráveis de scripts frágeis. Teste uma coisa por script, para que uma falha tenha uma causa óbvia. Mantenha os scripts independentes, para que possam ser executados em qualquer ordem. E faça asserções em valores estáveis, nunca em dados voláteis como IDs gerados ou carimbos de data/hora, que fazem um script falhar sem motivo real.
Duas maneiras de escrever scripts de teste de API
Para testes de API especificamente, existem duas abordagens comuns, e elas se adequam a diferentes equipes.
A abordagem code-first escreve scripts de teste em uma linguagem de propósito geral. Em Python, isso significa um framework como pytest mais uma biblioteca HTTP; em JavaScript, um test runner mais fetch. Você escreve a requisição, as asserções e a configuração como código real, e os scripts vivem em seu repositório ao lado da aplicação.
Esta abordagem oferece controle programático total. Lógica complexa, fixtures personalizados e asserções incomuns são apenas código. O custo é que cada script é código que você escreve e mantém, a equipe precisa de habilidades na linguagem, e muito boilerplate, tratamento de autenticação, construção de requisições, parsing de respostas, é reescrito entre os scripts. Ela se adapta a equipes de engenharia que desejam testes versionados com o código e se sentem confortáveis em assumir essa manutenção.
A abordagem visual constrói o script de teste em uma ferramenta dedicada de teste de API. Você define a requisição, adiciona asserções clicando e encadeia requisições em cenários, sem escrever ou manter código de script para os casos comuns. Ferramentas como Apidog seguem este caminho.
Esta abordagem remove o boilerplate e torna os scripts legíveis por qualquer pessoa na equipe, não apenas por aqueles que conhecem a linguagem. Você ainda pode usar código personalizado para a lógica rara que o construtor visual não consegue expressar. Ela se adapta a equipes mistas, testes liderados por QA e qualquer pessoa que deseje uma suíte de testes funcionando rapidamente sem um projeto de script anexado.
Nenhuma está errada. A questão decisiva é quem mantém os scripts e se eles devem residir no repositório da aplicação. Para a maioria dos testes de API, a abordagem visual permite que uma suíte confiável funcione mais rapidamente com menos manutenção.
Escrevendo um script de teste de API automatizado no Apidog
Aqui está o fluxo completo para construir um script de teste de API durável visualmente.
Passo 1: Defina a requisição. Importe o endpoint para o Apidog a partir de um arquivo OpenAPI ou defina-o diretamente. Este é o passo de Organizar (Arrange); a requisição carrega seu método, caminho, cabeçalhos e corpo.
Passo 2: Adicione os dados de teste. Defina o payload de entrada para o caso que você está testando. Para cobrir muitas entradas com um único script, anexe um arquivo CSV ou JSON para que o script seja executado uma vez por linha; o teste orientado a dados (data-driven testing) substitui uma dúzia de scripts quase idênticos por um.
Passo 3: Escreva as asserções. Este é o cerne. Adicione verificações visuais: status igual ao código esperado, campos chave do corpo existem e têm os valores corretos, a resposta está em conformidade com o esquema, o tempo de resposta está dentro do orçamento. Para casos negativos, afirme o formato do erro, não apenas o código de falha. Resista à tentação de afirmar dados voláteis.
Passo 4: Encadeie requisições em um cenário. Fluxos de trabalho reais abrangem várias chamadas. Construa um cenário que faça login, crie um recurso, o leia novamente e o exclua, passando valores de um passo para o próximo. Cada passo é um script; juntos eles testam um fluxo completo.
Passo 5: Adicione lógica de script personalizada apenas onde for necessário. Para verificações que as asserções visuais não conseguem expressar, lógica condicional, valores computados, comparações entre requisições, adicione um pré ou pós-processador JavaScript. Mantenha isso mínimo; a maioria dos scripts nunca precisa disso.
Passo 6: Execute e leia o relatório. Execute o cenário. O Apidog executa cada script, avalia cada asserção e relata a verificação exata que falhou com os valores esperados e reais lado a lado.
Passo 7: Automatize a execução. Conecte o cenário ao CI/CD para que ele seja executado a cada commit. Um script de teste que só é executado quando alguém se lembra não é realmente automatizado. Baixe o Apidog para construir seu primeiro cenário.
Mantendo a saúde dos scripts de teste
Uma suíte de testes é algo vivo. Scripts que eram perfeitos no lançamento ficam desatualizados à medida que a API muda. Três práticas mantêm uma suíte confiável.
Atualize os scripts junto com a API, não depois dela. Quando o contrato de um endpoint muda, o script muda no mesmo commit. Um script que afirma um esquema antigo falha pelo motivo errado e corrói a confiança em todos os outros scripts.
Trate scripts instáveis como bugs reais. Um script que passa a maioria das vezes é pior do que nenhum script, porque ele ensina à equipe que o vermelho não significa quebrado. Rastreie a causa, geralmente estado compartilhado ou uma suposição de tempo, e corrija-a.
Revise os scripts como código de produção. Um script com asserções fracas, uma verificação apenas de status 200, parece verde e parece seguro enquanto testa quase nada. Um segundo leitor percebe isso.
Perguntas frequentes
Qual a diferença entre um caso de teste e um script de teste? Um caso de teste descreve a intenção em termos humanos, entrada, ação, resultado esperado. Um script de teste é a versão executável que uma máquina roda. O caso é o plano; o script é a implementação.
Preciso saber programar para escrever scripts de teste automatizados? Não para testes de API com uma ferramenta visual. No Apidog, você constrói requisições, asserções e cenários clicando, e escreve código apenas para lógica incomum. Frameworks code-first exigem as habilidades de linguagem.
Por que meus scripts de teste continuam quebrando? As causas usuais são asserções em dados voláteis, scripts dependendo do estado uns dos outros e não atualizar os scripts quando a API muda. Isole os dados de teste, mantenha os scripts independentes e atualize-os com o contrato.
Quantas asserções um script de teste deve ter? O suficiente para verificar genuinamente o resultado, tipicamente status, campos chave do corpo, esquema e tempo. Uma única asserção de código de status é muito pouco; ela passa enquanto a resposta está errada.
Os scripts de teste devem residir no repositório da aplicação? Com uma abordagem code-first, geralmente sim, para que os testes versionem com o código. Com uma ferramenta visual, os scripts residem na plataforma de teste e sincronizam com a definição da API. Ambas as abordagens funcionam; a consistência é mais importante do que a escolha.
Como escrevo scripts de teste antes da API ser construída? Escreva-os com base no design da API. Se você tiver uma especificação OpenAPI, pode definir requisições e asserções a partir dela, e então executá-las contra um servidor mock até que o endpoint real exista. Os scripts estarão prontos no momento em que a implementação for concluída.
Qual a diferença entre um script de teste e uma suíte de testes? Um script de teste executa uma única verificação. Uma suíte de testes é uma coleção de scripts agrupados para serem executados juntos, geralmente cobrindo uma API ou recurso inteiro. As suítes mantêm um conjunto crescente de scripts organizado e permitem executar uma ampla cobertura em um único comando.
Qual deve ser o comprimento de um script de teste automatizado? Tão curto quanto possível, mantendo as quatro partes: organizar, agir, verificar e limpar. Se um script for longo, geralmente está testando mais de uma coisa e deve ser dividido. Um comportamento por script facilita o diagnóstico de falhas.