As cinco atividades dentro do teste de API
Funcional. Um endpoint faz a coisa certa, inclusive com entrada inválida? Comece por aqui. Todo o resto parte disso.
Integração. As sequências produzem o resultado certo? É onde de fato está a maioria dos bugs que o usuário enxerga.
Contrato. Dois serviços concordam sobre o formato? Valioso quando os deploys são independentes, cego quanto à correção.
As outras duas são carga, que responde sobre capacidade e exige um gerador dedicado, e comportamento de segurança, que é basicamente verificação de autorização e pertence junto à cobertura funcional, e não a um exercício trimestral.
A ordem que vale a pena seguir
Funcional, nos endpoints que importam. Inclusive nos casos negativos. Todo o resto se apoia nisso.
Integração, nas jornadas reais dos seus usuários. De três a cinco passos cada uma, não doze.
Verificações de autorização em todo lugar. São baratas, e a autorização em nível de objeto é a falha de API mais explorada.
Contrato, se os serviços têm deploy independente. Pule essa etapa se você sobe tudo junto.
Carga, antes dos releases. Por último, porque testar carga em um endpoint incorreto mede a velocidade com que você consegue errar.
Os quatro problemas, qualquer que seja a ferramenta
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 esses pontos como Auto-Authentication, Dynamic Variables, Dependency Chains e Auto-Cleanup, descritos na documentação de teste de API.
Todo time encontra esses problemas na mesma ordem, e a maioria é pega de surpresa. Projetar pensando neles é a diferença entre uma suíte que dura e outra que acaba em quarentena.
A asserção que mais importa
Faça asserções sobre o corpo da resposta, não apenas sobre o status. Um 200 que traz uma lista vazia onde deveria haver um registro é um bug que a verificação de status dá como aprovado. Esse único hábito pega mais defeitos reais do que qualquer outra mudança isolada.
Os dez primeiros casos, na prática
Se a suíte está vazia, a parte mais difícil é decidir por onde começar, e uma resposta genérica desperdiça uma semana. Esta lista funciona para a maioria dos produtos.
Três para o objeto principal do seu produto: criar, buscar de volta e fazer asserções sobre os campos, excluir e confirmar que sumiu. Dois para autorização: a mesma busca sem credenciais e com as credenciais de um segundo usuário. Dois para entrada: um campo obrigatório ausente e um valor fora do intervalo. Dois para aquela sequência que dá um frio na barriga antes de um release, seja qual for a sua. Um para o endpoint que quebrou da última vez.
Dez casos, o trabalho de uma manhã, e eles cobrem os formatos que geram a maior parte dos incidentes. A expansão a partir daí deve ser guiada pelo que realmente dá errado, e não por uma meta de cobertura, porque o segundo caminho produz suítes grandes e fora do ponto.
Por onde começar hoje
Aponte um projeto para o seu serviço, deixe a descoberta enumerar o que existe e leia o plano gerado antes de rodar qualquer coisa. O plano conta mais sobre a sua API do que os primeiros resultados, e é nele que o seu conhecimento do produto entra.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Se você prefere não instalar nada, o dashboard faz a mesma coisa. Todo o resto que a linha de comando consegue fazer está no repositório da CLI.
O GitHub App é um webhook que você configura no dashboard da TestSprite. Ele escuta o evento de deploy que seu pipeline já produz, então nada muda no seu repositório.
GitHub Actions coloca a etapa dentro do seu próprio workflow, configurada pelo terminal.
Onde a TestSprite se encaixa entre as cinco
Funcional, integração e a metade comportamental da segurança. Ela exercita o serviço em execução, gera planos a partir de uma passagem de descoberta somada à sua especificação e cobre os casos negativos que as suítes escritas à mão deixam de fora.
Auto-Authentication mantém as sessões vivas ao longo de toda a 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. Esses quatro são o que decide se uma suíte sobrevive ao primeiro ano, em qualquer ferramenta, e tê-los como produto é a diferença entre estender a suíte e ficar dando manutenção nela.
Teste de contrato e carga continuam sendo instrumentos separados, e isso roda ao lado dos dois. O que você ganha é a camada onde vive a maior parte dos defeitos visíveis para o usuário, coberta sem um framework próprio e rodando a cada pull request.
De quanta cobertura precisamos?
Cubra as jornadas que seria vergonhoso quebrar, mais todo endpoint que envolve dinheiro ou permissões. Expanda a partir dos incidentes, não em direção a uma porcentagem.
Devemos testar em produção?
Teste em um ambiente representativo. Criar e excluir registros em produção para satisfazer uma suíte de testes carrega um risco próprio.
Precisamos de uma especificação?
Ajuda, mas não é obrigatória. Uma passagem de descoberta sobre o serviço em execução somada a um documento de requisitos já gera um plano utilizável.
E quanto a mocks?
Faça mock dos terceiros que você não controla. Fazer mock do seu próprio serviço é testar o mock.
Com que frequência a suíte deve rodar?
A cada pull request para funcional e integração, em uma agenda fixa para carga. Uma suíte que roda uma vez por semana encontra os problemas com uma semana de atraso.
Cinco atividades, uma ordem.
Teste de API significa funcional, integração, contrato, carga e comportamento de segurança. Faça funcional e integração primeiro, adicione verificações de autorização em todo lugar e projete desde o início pensando em sessões, valores capturados, ordenação e limpeza.