Tests y Larastan antes de actualizar Laravel

Hola, bienvenido. En esta lección vamos a preparar las comprobaciones de la actualización antes de cambiar composer.json: los tests, Larastan y Pint en verde, y un script composer qa que los encadena para que comprobar el proyecto sea un solo comando. También vamos a ver con composer audit los avisos de seguridad abiertos de Laravel 10, que son el motivo principal para actualizar.

¿Por qué no empezamos ya con la actualización, si el proyecto funciona? Porque sin los tests no sabríamos qué ha dejado de funcionar. Cuando subamos a Laravel 11 van a fallar a la vez varias de las piezas que vimos en la lección anterior. Si los tests y el análisis estático están en verde ahora, cada fallo de las lecciones siguientes aparecerá con su mensaje exacto y sabremos que lo ha causado el cambio que acabamos de hacer, y no algo que ya fallaba antes. Y cada herramienta detecta una cosa distinta: los tests ven lo que falla al ejecutar el código, Larastan ve lo que ha cambiado de firma sin ejecutar nada, y Pint mantiene el estilo para que los diffs de cada commit solo lleven los cambios de la actualización.

El proyecto tiene tests de Pest para cada flujo: la autenticación de Breeze, los tickets por rol, la clasificación, la API con tokens, los adjuntos, el webhook, el cálculo del SLA, el comando programado y la protección CSRF. Vamos a lanzarlos:

80 tests en verde, en menos de 5 segundos. Fíjate en que corren contra MySQL y no contra SQLite: Sail crea la base de datos testing la primera vez que arranca el contenedor de MySQL, y phpunit.xml apunta a ella con DB_DATABASE=testing. Esto tiene una consecuencia para la actualización: la guía de Laravel 11 exige SQLite 3.26 o superior, y como aquí los tests usan la misma base de datos que el proyecto, ese requisito no nos afecta. Si tus tests usan SQLite en memoria, es un punto más que revisar.

De todos estos tests, apunta SlaTest, AssignRoleTest y CsrfProtectionTest: los 2 primeros van a enseñarnos los fallos de Carbon 3 y de Spatie Permission 6, y el tercero confirmará que el webhook sigue fuera del CSRF cuando migremos la estructura. El resto están para confirmar que lo que no debería cambiar, no cambia.