Skip to main content

Manejo de errores y escenarios límite

Cuando las cosas fallan: probar errores y escenarios límite en backend​

Un backend profesional no se define solo por responder bien cuando todo va según lo previsto, sino por cómo se comporta cuando algo falla.

En sistemas reales, los errores no son raros ni excepcionales: forman parte del funcionamiento normal.

Por eso, el manejo de errores y los escenarios límite no son un “extra”. Son una responsabilidad explícita del diseño y deben estar cubiertos por pruebas.

Las pruebas orientadas a errores no buscan romper el sistema. Buscan algo mucho más importante: verificar que falla de forma controlada, predecible y segura.

Un buen juego no es el que nunca falla, sino el que, cuando ocurre un bug o una situación inesperada, no se bloquea ni muestra pantallas rotas. Vuelve al menú, carga el último punto seguro o muestra un mensaje claro. El backend debe comportarse igual.

El error como parte del contrato del sistema​

Desde el punto de vista del consumidor (frontend, app móvil u otro servicio), un error también es una respuesta válida.

Por tanto, forma parte del contrato de la API.

Eso implica reglas claras:

  • Códigos HTTP coherentes
  • Estructura de error consistente
  • Mensajes comprensibles pero seguros

Un error mal gestionado rompe el contrato igual que una respuesta incorrecta en un caso exitoso.

Escenarios límite que deben probarse​

Un backend real debe contemplar explícitamente una serie de situaciones que no son ideales, pero sí inevitables. Estas situaciones deben probarse de forma consciente.

Recursos inexistentes​

Uno de los casos más comunes es solicitar algo que no existe.

  • Un ID que no está en la base de datos
  • Una relación inexistente entre entidades
  • Un recurso eliminado previamente

El backend debe responder de forma clara, normalmente con 404, y con un mensaje sin ambigüedades.

Probar este caso garantiza que:

– No se devuelven valores nulos confusos

– No aparecen errores genéricos

– El cliente puede reaccionar correctamente

En términos de juego: intentar entrar en un nivel que no existe debe mostrar “nivel no disponible”, no bloquear el juego.

Datos incompletos o mal formados​

Otro grupo crítico de escenarios límite está en los datos de entrada.

  • Campos obligatorios ausentes
  • Tipos incorrectos (texto en lugar de número)
  • Valores fuera de rango
  • JSON mal formado

Las pruebas deben confirmar que estos casos se detectan antes de ejecutar la lógica de negocio, devolviendo errores como 400 Bad Request.

Esto protege tanto al sistema como a los datos que gestiona.

Fallos internos simulados​

No todos los errores vienen del usuario. Algunos vienen del propio sistema.

  • Excepciones inesperadas
  • Dependencias externas que no responden
  • Estados internos inválidos

En testing, estos fallos se simulan forzando errores mediante mocks o stubs. El objetivo no es entender la causa, sino comprobar que:

  • El sistema no se cae
  • La respuesta es un error controlado (500, u otro definido)
  • No se filtran detalles internos

Es como desconectar un sensor del juego para comprobar que el motor no se bloquea, sino que muestra un mensaje genérico y sigue funcionando.

Estados inesperados​

Algunos errores aparecen por estados que no deberían existir, pero pueden darse por datos heredados o fallos previos.

  • Usuarios activos sin permisos asignados
  • Recursos con relaciones incompletas
  • Estados intermedios inconsistentes

Las pruebas de estos casos validan que el backend no asume condiciones ideales y sabe reaccionar incluso cuando el estado interno no es el esperado.

Coherencia en los errores​

Un backend robusto no solo devuelve errores correctos, sino errores coherentes.

Esto implica:

  • Mismo formato de error en toda la API
  • Mensajes consistentes para el mismo tipo de fallo
  • Separación clara entre errores del cliente (4xx) y del servidor (5xx)

Las pruebas deben verificar esta coherencia, ya que muchos clientes gestionan errores de forma automática.

Relación con seguridad y estabilidad​

Un mal manejo de errores no es solo un problema de calidad. También es un problema de seguridad.

  • Mensajes internos revelan estructura del sistema
  • Stack traces facilitan ataques
  • Respuestas incoherentes permiten inferir estados internos

Por eso, probar errores y escenarios límite es también testing defensivo.

Idea clave para desarrollo profesional​

Un backend maduro no se define por cuántas funcionalidades tiene, sino por cómo se comporta cuando algo va mal. Probar errores convierte el fallo en un comportamiento esperado, documentado y controlado. El error deja de ser una sorpresa en producción y pasa a ser parte estable del sistema. Ese enfoque transforma el backend en un componente predecible, seguro y confiable, incluso en condiciones adversas.