Os quatro níveis do teste funcional de API
1. Status
Retornou 200.
Detecta quedas. Passa tranquilamente com um resultado vazio onde deveria haver um registro.
2. Estrutura
Os campos esperados estão presentes com os tipos esperados.
Detecta desvios de schema. Não diz nada sobre os valores estarem certos.
3. Valor
O total é de fato a soma, o status é aquele que essa ação deveria produzir.
Onde os defeitos reais começam a ser pegos.
O quarto é o de relacionamento: depois de criar um pedido, buscar o cliente mostra esse pedido. A maioria dos bugs interessantes vive entre duas chamadas, e não dentro de uma, e o nível quatro é o único que olha para lá.
Por que as suítes param no nível dois
Porque os níveis três e quatro precisam saber o que significa estar correto, e isso exige que alguém decida. Status e estrutura podem ser derivados mecanicamente de uma especificação. Valor e relacionamento exigem um julgamento sobre o produto.
Isso é realmente mais difícil, e é também todo o valor. Uma suíte que nunca expressa uma regra de produto está verificando, de um jeito elaborado, que o serviço está no ar.
O caso negativo que as pessoas pulam
Para cada endpoint, pergunte o que deveria ser rejeitado e depois afirme que é. Valores fora do intervalo, campos obrigatórios ausentes, um identificador que pertence a outra pessoa. Serviços que retornam 200 com um objeto de erro no corpo são comuns o bastante para que uma suíte que desconhece esse padrão reporte verde para sempre.
O que uma suíte precisa 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. A TestSprite trata disso como Auto-Authentication, Dynamic Variables, Dependency Chains e Auto-Cleanup, descritos na documentação de testes de API.
Acertar esses pontos é o que permite gastar sua atenção nos níveis três e quatro em vez de em infraestrutura.
Levando a cobertura além da parte rasa
Os planos gerados partem de uma especificação ou de uma passagem de descoberta e incluem as categorias funcional, de schema, de autorização, de tratamento de erros e de limites, então os casos negativos existem por padrão, em vez de dependerem de alguém lembrar deles no fim de uma sprint.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
A mesma configuração está disponível no dashboard da TestSprite, caso você prefira não instalar nada localmente. O resto da superfície da CLI está no repositório da CLI.
Escolhendo quais endpoints recebem o nível quatro
As asserções de relacionamento são as mais valiosas e as mais caras, então elas não devem estar em todo lugar. O filtro que funciona é perguntar quanto custaria uma resposta errada.
Tudo que movimenta dinheiro, altera permissões ou serve de base para uma decisão que outra pessoa toma recebe o nível quatro. Um pedido que existe mas não está vinculado a um cliente, uma concessão de permissão que funcionou só de um lado, um relatório internamente consistente que discorda dos registros de origem. Essas são as falhas caras e silenciosas.
Endpoints de relatório somente leitura, health checks e qualquer coisa cuja saída alguém confere na hora não precisam disso. Ser deliberado nessa escolha é o que mantém a suíte rápida o bastante para as pessoas rodarem.
Rode a cada mudança
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 de GitHub Actions coloca a verificação no repositório, onde ela é revisada como o resto do build.
Como a TestSprite leva você além do nível dois
Os planos gerados incluem os casos negativos por padrão, nas categorias funcional, de schema, de autorização, de tratamento de erros e de limites, que é justamente onde a maioria das suítes escritas à mão perde o fôlego. Você os refina em linguagem natural, e é nesse refinamento que o seu conhecimento do produto entra na suíte.
Os níveis de valor e de relacionamento são os que merecem sua atenção, e também são os que precisam de alguém que conheça o produto. 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, de modo que o tempo que você gasta vai para o que significa estar correto, e não para infraestrutura.
O que você ganha é uma suíte que faz asserções sobre os corpos de resposta e sobre os relacionamentos entre chamadas, rodando a cada mudança, em vez de um pipeline verde que prova que o serviço está no ar.
A asserção de código de status é inútil?
Não, ela é só o piso. Mantenha e adicione pelo menos uma asserção de nível de valor em cada endpoint que importa.
Como decidir o que significa estar correto?
Pergunte o que o produto promete, não o que o código faz. Se ninguém souber responder para um determinado endpoint, essa ambiguidade já vale ser trazida à tona.
Todo endpoint precisa dos quatro níveis?
Não. Reserve os níveis três e quatro para os endpoints em que um valor errado tem consequências. Endpoints de relatório e health checks não precisam deles.
E as asserções geradas?
Úteis para os níveis um e dois, que são mecânicos. Os níveis três e quatro se beneficiam de revisão, porque é aí que o conhecimento do produto entra.
Quantos casos negativos por endpoint?
Um ou dois que importam valem mais do que dez que enumeram toda entrada inválida possível. Escolha as rejeições que um cliente real provocaria.
Status e estrutura são o piso, não o trabalho.
O teste funcional de API tem quatro níveis de asserção e a maioria das suítes para no segundo. As asserções de valor e de relacionamento são onde os defeitos são pegos, e o caso negativo é o que as pessoas pulam.