La verdad incómoda: tests verdes no aseguran éxito en prod. ⚠️

La semana pasada desplegué una API Python. Tests en verde. Todo parecía perfecto. Lunes, un 30% de errores 500 en producción. ¿Mis tests? Seguían pasando en local.

Este es un escenario demasiado común para muchos ingenieros: confiar ciegamente en mocks que solo validan el "happy path". Cuando la realidad de una API externa es volátil, imperfecta o cambiante, nuestros sistemas se rompen. El problema no es que los tests fallen, sino que son engañosamente exitosos.

Creemos que cubrimos los casos, pero en realidad, estamos validando una ficción. La verdad es que los datos externos rara vez son tan prístinos como los que imaginamos en nuestros mocks.

Entonces, ¿cómo blindamos nuestras APIs?

• Adoptar accesos defensivos: Utilizar `dict.get(key, default)` en lugar de `dict[key]`. Esto protege contra `KeyError` cuando los campos esperados están ausentes, proporcionando resiliencia inmediata.

• Mocks con caos controlado: Tus mocks deben simular la imperfección de los datos reales. No asumas una estructura ideal; introduce escenarios de campos faltantes o tipos inesperados.

• Expandir la cobertura a "edge cases": No solo pruebes el camino feliz. Incorpora tests específicos para datos incompletos, respuestas vacías o variaciones de estructura, tal como la API externa podría devolverlos.

Mis tests "perfectos" no me enseñaron nada. Fue producción la que me mostró la realidad. La resiliencia no es solo manejar errores, es anticipar la imperfección.

¿Qué estrategias están usando ustedes para testear la robustez de sus integraciones con APIs externas y manejar la variabilidad de datos?