Métodos de teste de API pelo que cada um encontra de exclusivo
Smoke
Encontra: o deploy está quebrado.
Custo: minutos. Rode sempre. Nada mais te avisa tão rápido.
Funcional
Encontra: comportamento errado em um endpoint, inclusive com entrada inválida.
Custo: moderado. A base que todo o resto pressupõe.
Integração
Encontra: sequências que falham mesmo com cada passo passando.
Custo: mais alto, por causa do estado. Maior retorno para bugs visíveis ao usuário.
Regressão não é um método à parte, é uma cadência: rodar o que você já tem a cada mudança. Contrato encontra divergências de formato entre serviços implantados de forma independente. Carga encontra limites de capacidade. Fuzz encontra quebras diante de entradas malformadas. Comportamento de segurança encontra erros de autorização e custa muito menos do que sua fama sugere.
O que as pessoas classificam errado
O teste de regressão entra na lista como um método e depois é agendado como uma atividade, geralmente antes das releases. É aí que está o erro. Regressão é o que seus testes existentes fazem quando rodam, e o valor deles depende quase inteiramente da frequência com que isso acontece. Uma suíte de regressão executada uma vez por mês é uma suíte que encontra problemas com um mês de atraso.
Como escolher sem fazer todos
Smoke mais funcional nos endpoints críticos. A cobertura útil mais barata que existe.
Integração nas jornadas reais. Onde realmente moram os bugs que seus usuários encontram.
Verificações de autorização. Baratas, e a falha mais explorada em APIs reais.
Contrato, só se os serviços forem implantados de forma independente.
Carga e fuzz, quando o que está em jogo justificar. Os dois são reais e os dois são o primeiro investimento errado.
Caixa-preta contra caixa-branca
Uma distinção que importa menos do que já importou no trabalho com API. Testar pela interface pública é o padrão certo porque é isso que seus clientes usam. O conhecimento de caixa-branca serve para escolher o que testar, não para definir como testar.
Onde a pirâmide engana no caso das APIs
A pirâmide de testes foi desenhada para um mundo de unidades e interfaces de usuário, e aplicá-la diretamente ao trabalho com API leva a um erro comum.
A pirâmide manda ter poucos testes lentos no topo. Para APIs, a camada cara não é óbvia: um teste de API é muito mais barato que um teste de navegador e muito mais caro que um teste de unidade, e encontra coisas que nenhum dos dois encontra. Times que encaixam os testes de API no topo estreito da pirâmide acabam com poucos demais, e times que os encaixam na base larga acabam com uma suíte lenta e cheia de asserções triviais.
Um modelo mental melhor para serviços é perguntar qual camada consegue responder a uma determinada pergunta. Se um cálculo está certo é assunto de teste de unidade. Se o endpoint o aplica corretamente é assunto de teste de API. Se o usuário chega até ele é assunto da camada acima das duas. Aí as proporções saem do seu produto, e não de um diagrama.
O que todos os métodos exigem por baixo
Quatro coisas decidem se uma suíte de API sobrevive ao primeiro ano: sessões que expiram, valores que só existem em tempo de execução, chamadas que dependem umas das outras e registros que ninguém limpa. O TestSprite cuida disso com Auto-Authentication, Dynamic Variables, Dependency Chains e Auto-Cleanup, descritos na documentação de teste de API.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
O dashboard cobre o mesmo terreno para quem não quer uma instalação local, e o conjunto completo de comandos está no repositório do CLI.
São dois caminhos, e a escolha é, na verdade, sobre quem é dono do pipeline. Conectar o GitHub App pelo dashboard não exige nenhuma mudança no seu repositório, porque ele reage ao deployment que seu build já emite. Adicionar um passo do GitHub Actions coloca a verificação dentro do repositório, onde ela é revisada como o resto do build.
Quais métodos o TestSprite cobre
Funcional e integração, mais a parte comportamental de segurança, mais regressão como cadência em vez de atividade. Os planos gerados abrangem as categorias funcional, de schema, de autorização, de tratamento de erros e de limites, refinados em linguagem simples.
Auto-Authentication mantém as sessões vivas ao longo de uma execução, Dynamic Variables levam valores de uma chamada para outra, Dependency Chains derivam a ordem de execução a partir do que cada caso precisa e produz, e Auto-Cleanup remove exatamente o que a execução criou. É isso que permite que a regressão seja de fato contínua, em vez de algo agendado antes das releases, o que é o maior determinante isolado de qualquer método dar retorno.
Contrato, carga e fuzzing continuam sendo instrumentos separados. A vantagem é que os três métodos de maior retorno deixam de disputar tempo de escrita com o trabalho de features, então a cobertura existe em vez de ficar apenas planejada.
Qual método encontra mais bugs?
Integração, na maioria dos produtos, porque as falhas visíveis ao usuário costumam surgir entre chamadas, e não dentro de uma.
Vale a pena ter uma suíte separada só de smoke?
Sim. Uma verificação de dois minutos que roda a cada deploy tem uma função diferente da de uma suíte de vinte minutos, e misturar as duas faz com que nenhuma rode na hora certa.
Precisamos de teste de fuzz?
Se entradas malformadas chegando ao seu serviço têm consequências reais, sim. Para a maioria das APIs internas, ele fica abaixo das verificações de autorização e da cobertura de integração em prioridade.
E o teste exploratório de API?
Genuinamente valioso e não automatizável. Faça quando uma API é nova ou mudou bastante, e depois converta em testes o que você encontrou.
Como isso se encaixa na pirâmide de testes?
De forma frouxa. A pirâmide foi desenhada para unidade e UI. Para APIs, o eixo útil é o que cada verificação encontra de exclusivo, e não a qual camada ela pertence.
Escolha pelo que cada método encontra de exclusivo.
Vale mais ordenar os métodos de teste de API por custo contra retorno exclusivo do que decorá-los. Smoke e funcional primeiro, integração para os bugs de verdade, verificações de autorização porque são baratas, e carga por último.