Tests inestables en Laravel: Por qué tu CI falla aleatoriamente

La crisis de confianza en tu suite de pruebas

¿Te resulta familiar esta situación? Tu suite de pruebas pasa localmente, pero al subir el código a producción, el pipeline de integración continua (CI) falla. Vuelves a ejecutar el proceso sin cambiar una sola línea de código y, mágicamente, todo funciona. Estás lidiando con flaky tests o pruebas inestables.

En la programación moderna, estas pruebas son un problema grave. No solo consumen tiempo, sino que generan una falsa sensación de incertidumbre. Cuando los desarrolladores pierden la fe en su suite de tests, comienzan a ignorar los fallos reales, lo que inevitablemente termina en errores críticos en el entorno de producción.

Las causas ocultas de la inestabilidad

Contrario a lo que muchos piensan, la inestabilidad rara vez proviene de PHPUnit. Generalmente, es el resultado de una arquitectura descuidada. Al igual que cuando optimizamos nuestro entorno de desarrollo siguiendo guías sobre cómo mejorar la programación y gestión de archivos en WSL, la clave reside en el aislamiento y la previsibilidad.

1. El factor tiempo y la aleatoriedad

El uso de Carbon para manipular el tiempo es potente, pero si no se controla, es una fuente de caos. Si una prueba depende del tiempo actual, el resultado variará según la carga del servidor o la latencia.

La solución es fijar el tiempo con Carbon::setTestNow() y asegurarse de limpiarlo después de cada ejecución.

2. Contaminación de la base de datos

Las pruebas nunca deben depender de registros creados por tests anteriores. Si tus tests comparten el mismo estado, cualquier cambio en el orden de ejecución provocará fallos. Utiliza siempre RefreshDatabase o DatabaseTransactions para garantizar un entorno limpio.

3. El peligro de la asincronía en las colas

Las queues son otra fuente de frustración. Si pruebas un comportamiento inmediatamente después de despachar un job, es probable que la aserción se ejecute antes de que el trabajo termine. La recomendación es clara:

• Usa Bus::fake() para verificar el despacho.
• Cambia la configuración a sync durante el entorno de test.

Escalabilidad y pruebas deterministas

El uso de herramientas modernas, similar a cómo exploramos en The Evolution of Programming: Optimizing the Stack with AI and Modern Tools, nos obliga a pensar en la escalabilidad. La ejecución paralela de tests no crea inestabilidad; simplemente expone problemas latentes como claves de Redis compartidas o variables estáticas.

Buenas prácticas para un código robusto:

• Evita dependencias implícitas: Cada test debe ser capaz de ejecutarse de forma aislada y en cualquier orden.
• Mockea APIs externas: Nunca dependas de servicios de terceros que puedan introducir latencia o errores de red.
• Factories deterministas: Define explícitamente el estado de tus modelos en lugar de confiar en datos aleatorios.

Conclusión

Los flaky tests no son un error de azar; son un síntoma de una arquitectura que necesita mayor rigor. Al igual que en el ecosistema open source o al trabajar con javascript, la calidad de nuestro software depende de nuestra capacidad para crear sistemas deterministas. Eliminar la incertidumbre no solo hace que el CI sea más rápido, sino que devuelve la paz mental al equipo de desarrollo.