Por que os testes de integração de API precisam de um grafo explícito
| A ordem passa a ser acidental | Os testes passam na ordem que o executor escolheu por acaso e falham em outra máquina. Alguém adiciona um plugin de ordenação e o problema se torna permanente. |
| Uma falha parece vinte | A criação falha, tudo que vem depois falha e você recebe uma tela vermelha. Encontrar a primeira falha real vira o trabalho. |
| Paralelismo não é seguro | Sem saber o que depende do quê, você não consegue executar nada em paralelo com segurança. Então as suítes continuam sequenciais e lentas. |
Tornando isso explícito
A solução é cada teste declarar o que precisa e o que produz. Com isso, o executor deriva uma ordem segura, ramos independentes rodam em paralelo e uma falha marca seus dependentes como ignorados em vez de falhos. Vinte linhas vermelhas viram uma falha e dezenove testes ignorados, o que é uma experiência de depuração completamente diferente.
Essa é a diferença entre os Endpoint Tests, que cobrem uma rota por vez, e os Integration Tests, que são cadeias de várias etapas em que uma resposta alimenta a próxima.
O problema da passagem de valores
Uma criação retorna um identificador de que as etapas seguintes precisam. Fixe-o no código e o teste funciona exatamente uma vez. Capture-o e a cadeia leva os dados adiante como deveria. Escrito assim parece trivial, e é a razão mais comum para uma suíte que passava no mês passado falhar hoje.
Limpeza dentro de uma cadeia
Testes de integração criam mais estado do que testes de endpoint, e criam esse estado em uma ordem de dependência que a limpeza precisa respeitar. Você não pode excluir o cliente antes do pedido. Uma limpeza atrelada ao que aquela execução criou, na ordem inversa das dependências, é a única versão que sobrevive à concorrência.
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 trata disso como Auto-Authentication, Dynamic Variables, Dependency Chains e Auto-Cleanup, descritos na documentação de testes de API.
O que fazer quando uma cadeia falha na etapa quatro
O valor de declarar dependências aparece com mais clareza na forma como uma falha se apresenta, e vale conhecer a ordem de leitura.
Primeiro, verifique se a falha está na etapa ou nas entradas dela. Uma etapa que recebeu o identificador errado falhou porque algo anterior produziu a coisa errada, e corrigir a etapa seria corrigir o sintoma.
Segundo, verifique se ela falha a partir de um estado limpo. Uma cadeia que funciona uma vez e falha na reexecução está dizendo que a limpeza não aconteceu, o que é um bug diferente daquele que você está olhando e, muitas vezes, o mais importante.
Terceiro, só então olhe para o endpoint em si. Na maioria das vezes a informação interessante estava nas duas primeiras verificações, e é por isso que uma lista plana de linhas vermelhas custa muito mais para depurar do que um grafo com uma falha e dezenove testes ignorados.
Mantenha as cadeias curtas
Uma cadeia de doze etapas que falha na etapa nove é difícil de diagnosticar e lenta de reexecutar. De três a cinco etapas cobrindo uma única intenção do usuário é o tamanho que continua útil. Cadeias longas geralmente significam que duas jornadas foram misturadas.
Como começar
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Se você prefere não instalar nada, o painel faz a mesma coisa. Todo o resto que a linha de comando pode fazer está no repositório do CLI.
Conecte o repositório pelo painel e as execuções partem do deploy que você já gera, ou então adicione uma etapa ao seu próprio workflow.
Como o TestSprite torna o grafo explícito
Cada caso declara o que precisa e o que produz, e os Dependency Chains derivam daí uma ordem de execução segura. Ramos independentes rodam em paralelo e, quando algo falha, seus dependentes são marcados como ignorados em vez de falhos, então vinte linhas vermelhas viram uma falha e dezenove testes ignorados.
Dynamic Variables cuidam da passagem de valores, então a cadeia carrega o identificador que a chamada de criação retornou, e não um número que alguém colou. O Auto-Cleanup remove o que cada execução criou, na ordem inversa das dependências, e é isso que torna seguras as execuções concorrentes.
O benefício aparece na primeira vez que uma cadeia quebra. Você recebe uma única falha que aponta onde tudo divergiu, em vez de uma tela vermelha inteira para ler, o que é a diferença entre um diagnóstico de cinco minutos e uma tarde inteira.
Qual é a diferença em relação aos testes end-to-end?
End-to-end normalmente significa passar pela interface. Os testes de integração de API exercitam as mesmas jornadas na camada de serviço, o que é mais rápido e mais preciso sobre onde a falha aconteceu.
Os testes de integração devem usar dependências reais?
Em testes de integração, sim, é exatamente esse o ponto. Simular com mock aquilo com que você está integrando responde a outra pergunta.
Como lidar com os dados de teste entre as etapas?
Capture o que cada etapa produz e passe adiante. Dados pré-carregados compartilhados são convenientes até duas cadeias tocarem o mesmo registro.
E os serviços de terceiros dentro de uma cadeia?
Use o sandbox deles quando existir. Quando não existir, isole essa etapa e aceite que a cadeia tem um limite.
De quantos testes de integração precisamos?
Um por jornada de usuário que importa, não um por combinação de endpoints. As combinações são infinitas; as jornadas, não.
Declare o grafo ou depure-o para sempre.
Testes de integração de API são sobre sequências, e sequências têm um grafo de dependências. Declarar o que cada teste precisa e o que produz dá a você ordenação segura, paralelismo e falhas legíveis. Capture valores em vez de fixá-los no código e mantenha as cadeias curtas.