Quickmock

Probar la lógica de reintento y back-off

Un mock que falla primero, luego tiene éxito — para que puedas demostrar que tu código de reintento funciona.

El código de reintento es difícil de probar porque las APIs reales rara vez fallan cuando tú quieres. Un mock con una secuencia de respuestas arregla eso: la primera llamada devuelve 500, la siguiente devuelve 200, y el ciclo se repite. Eso te da un fallo determinista en el que tu conjunto de pruebas puede confiar.

¿Cómo hacer que una llamada falle una vez y luego tenga éxito?

Define la respuesta por defecto como el fallo y añade una secuencia de respuestas para lo que viene después. El mock recorre la secuencia una posición por llamada y luego vuelve a empezar, de modo que un único endpoint produce el patrón fallar-y-luego-acertar que necesita toda prueba de reintentos, en un orden fijo y sin aleatoriedad que vuelva inestable la prueba.

El determinismo es justamente la clave. Probar reintentos contra un endpoint genuinamente inestable te deja una suite que pasa o falla por motivos ajenos a tu código. Si de verdad quieres aleatoriedad — para una prueba de resistencia y no para una prueba unitaria — la herramienta correcta es una tasa de error, no una secuencia.

¿Cómo verificas el back-off y no solo el recuento de reintentos?

Contar intentos demuestra que reintentaste; no demuestra que esperaste. Registra la marca de tiempo de cada entrega en el inspector y comprueba que los intervalos crecen como dice tu política. Los reintentos a intervalo fijo de todos los clientes a la vez son justo lo que convierte una caída breve en una prolongada, y por eso el consejo estándar es el back-off exponencial con jitter.

Añade un retardo de respuesta al mock para probar la otra mitad del problema: una petición que se cuelga en lugar de fallar. Un cliente con reintentos pero sin timeout esperará indefinidamente en el primer intento y no llegará nunca al reintento.

¿Qué fallos deberían reintentarse realmente?

Reintentarlo todo es tan incorrecto como no reintentar nada. Un 500 o un 503 merecen otro intento; un 400 o un 422 fallarán igual para siempre y el reintento solo multiplica el error. El 429 es un caso aparte: respeta la cabecera Retry-After en lugar de aplicar tu propio calendario.

Simula cada uno de estos como un endpoint independiente y comprueba el comportamiento que quieres: reintentado, no reintentado, o aplazado hasta que lo diga el servidor. Tres mocks pequeños documentan tu política de reintentos con más precisión que cualquier comentario.

Pasado cierto punto, deja de reintentar y falla de forma ruidosa. Un circuit breaker que se abre tras varios fallos os protege a ti y al servicio al que llamas: reintentar indefinidamente convierte la caída de una dependencia en la tuya propia, y además la esconde de tus alertas mientras lo hace.

¿Qué suele salir mal?

  • Reintentar solicitudes no idempotentes. Un POST reintentado puede cobrar una tarjeta dos veces.
  • Sin límite. Reintentos sin límite convierten un apagón corto en un apagón de tu propia creación.
  • Reintento sin tiempo de espera. Si el primer intento nunca vuelve, el reintento nunca se ejecuta.
  • Reintentos sincronizados. Sin jitter (fluctuación), todos los clientes reintentan al mismo tiempo y el servicio que se está recuperando es golpeado por toda la flota a la vez.

Cuándo usar esto

El código de reintento es notoriamente poco probado porque las APIs reales rara vez fallan a pedido. Este mock devuelve 500 en la primera llamada y 200 en la segunda, luego repite el ciclo, para que una prueba automatizada pueda afirmar que tu cliente reintenta y se recupera.

Crear el 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}" }
  ]
}'

Llamarlo

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

Lo que obtienes

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

Preguntas frecuentes

¿Es el orden de fallo determinista?
Sí. Una secuencia de respuestas se recorre en orden, un paso por llamada, y después se repite, así que la misma prueba produce la misma sucesión de estados en cada ejecución. Usa una tasa de error en su lugar solo cuando quieras aleatoriedad a propósito.
¿Cómo compruebo cuántas veces reintentó mi cliente?
El inspector enumera cada entrega con su marca de tiempo, así que el recuento es el número de solicitudes y el back-off son las brechas entre ellas.
¿Puedo simular una solicitud colgada en lugar de un error?
Sí: establece un retardo de respuesta. Es el caso que la mayoría de las pruebas de reintento se saltan: un cliente sin timeout se queda bloqueado para siempre en el primer intento y su lógica de reintento no llega a ejecutarse nunca.

Construye el tuyo propio

Crear un mock

Guías relacionadas

← Todas las guías

Última actualización: 2026-10-17