A ordem da falha é determinística?

Sim. Uma sequência de respostas é percorrida em ordem, um passo por chamada, e depois se repete — portanto, o mesmo teste produz a mesma sequência de status a cada execução. Use uma taxa de erros apenas quando quiser aleatoriedade deliberada.

Como verifico quantas vezes meu cliente tentou novamente?

O inspetor lista cada entrega com o respectivo timestamp, logo a contagem é o número de requisições e o back-off é o intervalo entre elas. É assim também que se descobre que um cliente está repetindo muito mais do que deveria.

Posso simular uma requisição que trava em vez de retornar erro?

Sim — defina um atraso na resposta. Esse é o caso que a maioria dos testes de repetição não cobre: um cliente sem timeout bloqueia para sempre na primeira tentativa e a lógica de repetição nunca roda.

Testar lógica de repetição e recuo (back-off)

Um mock que falha primeiro e depois acerta — para que você possa provar que seu código de repetição funciona.

Código de repetição é difícil de testar porque APIs reais raramente falham quando você deseja. Um mock com uma sequência de resposta corrige isso: a primeira chamada retorna 500, a próxima retorna 200, e o ciclo se repete. Isso lhe dá uma falha determinística em que sua suíte de testes pode confiar, para que você possa provar que a repetição realmente ocorreu e que a segunda tentativa foi bem-sucedida — em vez de presumir que seria.

Como você faz uma chamada falhar uma vez e depois ter sucesso?

Defina a resposta padrão como falha e adicione uma sequência de respostas para o que vem depois. O mock percorre a sequência uma vez por chamada e depois recomeça, de modo que um único endpoint produz o padrão de falha-então-sucesso que todo teste de repetição precisa, numa ordem fixa, sem aleatoriedade para deixar o teste instável.

Determinismo é a questão central. Testar repetições contra um endpoint genuinamente instável dá a você uma suíte de testes que passa ou falha por razões alheias ao seu código. Se você realmente quiser aleatoriedade — para um teste de estresse em vez de um teste de unidade — uma taxa de erro é a ferramenta certa em vez de uma sequência.

Como você verifica o recuo (back-off) e não apenas a contagem de repetições?

Contar as tentativas prova que você repetiu; não prova que você esperou. Registre a marca de tempo de cada entrega no inspetor e verifique se os intervalos crescem da maneira que sua política diz que deveriam. Repetições de intervalo fixo de todos os clientes ao mesmo tempo são o que transforma uma breve queda em uma prolongada, e é por isso que recuo exponencial com variação (jitter) é o conselho padrão.

Adicione um atraso na resposta do mock para testar a outra metade do problema: uma requisição que trava em vez de falhar. Um cliente com repetições mas sem timeout esperará indefinidamente na primeira tentativa e nunca chegará à repetição.

Quais falhas realmente devem ser repetidas?

Repetir tudo é tão errado quanto não repetir nada. Um 500 ou 503 vale outra tentativa; um 400 ou 422 falhará da mesma forma para sempre e a repetição apenas multiplica o erro. 429 é um caso próprio — respeite o cabeçalho Retry-After em vez de aplicar sua própria agenda.

Simule cada um desses como um endpoint separado e garanta o comportamento que você deseja: repetido, não repetido, ou adiado até que o servidor permita. Três pequenos mocks documentam sua política de repetição de forma mais precisa que qualquer comentário.

A partir de um certo ponto, pare de repetir e falhe explicitamente. Um circuit breaker que se abre após repetidas falhas protege tanto você quanto o serviço que você está chamando: tentar de novo para sempre converte a indisponibilidade da dependência na sua, e a esconde dos seus alertas enquanto faz isso.

O que geralmente dá errado?

Repetir requisições não idempotentes. Um POST repetido pode cobrar um cartão duas vezes. Repita com segurança apenas onde a repetição for inofensiva, ou use uma chave de idempotência.
Sem limite máximo. Repetições sem um teto transformam uma queda curta numa queda gerada por você.
Repetir sem timeout. Se a primeira tentativa nunca retornar, a repetição nunca vai rodar — teste o travamento, não apenas a falha.
Repetições sincronizadas. Sem jitter (variação), todos os clientes repetem no mesmo ritmo, e o serviço que está tentando se recuperar é atingido por toda a frota de uma vez.

Quando usar isso

Código de repetição é notoriamente não testado porque APIs reais raramente falham sob demanda. Este mock retorna 500 na primeira chamada e 200 na segunda, e depois entra em ciclo, então um teste automatizado pode garantir que seu cliente tenta de novo e se recupera. O cabeçalho X-Mockapi-Variant mostra qual passo serviu cada requisição.

Criar o mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 500,
  "content_type": "application/json",
  "response_body": "{\"error\":\"upstream\"}",
  "response_sequence": [
    { "status": 200, "body": "{\"ok\":true}" }
  ]
}'

Chamá-lo

curl https://quickmock.dev/m/<slug>

O que você obtém

1st call  -> 500  (X-Mockapi-Variant: seq-1/2)
2nd call  -> 200  (seq-2/2)
...then it cycles

FAQ

A ordem da falha é determinística?: Sim. Uma sequência de respostas é percorrida em ordem, um passo por chamada, e depois se repete — portanto, o mesmo teste produz a mesma sequência de status a cada execução. Use uma taxa de erros apenas quando quiser aleatoriedade deliberada.
Como verifico quantas vezes meu cliente tentou novamente?: O inspetor lista cada entrega com o respectivo timestamp, logo a contagem é o número de requisições e o back-off é o intervalo entre elas. É assim também que se descobre que um cliente está repetindo muito mais do que deveria.
Posso simular uma requisição que trava em vez de retornar erro?: Sim — defina um atraso na resposta. Esse é o caso que a maioria dos testes de repetição não cobre: um cliente sem timeout bloqueia para sempre na primeira tentativa e a lógica de repetição nunca roda.

Construa o seu próprio

Criar um mock

Guias relacionados

← Todos os guias

Última atualização: 2026-10-17