Cambias una regla de validación en un FormRequest. La CI, obediente, se traga cuatro mil tests durante once minutos, de los cuales más o menos tres tenían algún motivo real para ejecutarse. Todos hemos aceptado esto como el precio de la confianza. Pest 5 es la primera versión mayor en nuestro rincón del ecosistema que trata ese precio como negociable — y, lo que es más interesante, la primera que asume abiertamente que algunos de los diffs que aterrizan en tu repo nunca los tecleó una persona.

Mi postura, por delante: esa suposición es correcta, y construir un framework de testing alrededor de ella es el movimiento acertado, aunque partes de él envejezcan mal. Una suite que solo habla con humanos ya va por detrás de cómo se escribe código en 2026. Las funcionalidades más discutidas de Pest 5 — el plugin de Agent y los Evals — no son decoración de hype. Son la admisión de que el segundo usuario de tu suite de tests es una máquina, y esa máquina necesita que le digan cuándo se equivoca con la misma franqueza que a un dev junior en su primera pull request.

Primero, el inventario sobrio, porque el changelog se malinterpreta con facilidad. La versión mínima de PHP salta a 8.4. Por debajo, ahora estás sobre PHPUnit 13. Test Impact Analysis selecciona el subconjunto de tests relacionado con tu diff en lugar de dispararlo todo. PHPStan y Rector apuntan ahora a tu código de test, que históricamente ha sido el código menos analizado de cualquier repo Laravel que he tocado. Lo que no es historia de Pest 5: el testing de navegador llegó con Pest 4, y el sharding equilibrado por tiempo aterrizó ya en la 4.6. Si tu argumento de actualización ante el equipo se apoya en esos dos, alguien te lo señalará en la review, y con razón.

Test Impact Analysis merece tanto el aplauso como una etiqueta de advertencia. En local, convierte el hábito de ejecutar-los-tests-tras-cada-guardado de una fantasía en algo que harás de verdad, y un hábito que mantienes vale más que un ritual que te saltas. Pero piensa en cuánto de una app Laravel se cablea en tiempo de ejecución: bindings del contenedor intercambiados en un service provider, listeners registrados en un EventServiceProvider, comportamiento activado por config o por un morph map. Ninguna selección basada en el diff puede ver todo eso. Mi regla: tests impactados en cada guardado, suite completa antes de mergear. Trata la vía rápida como un explorador, no como el veredicto.

El plugin de Agent es donde las opiniones se dividen en las barras de las conferencias. La idea: un asistente de código no debería corregirse sus propios deberes releyendo su diff — debería poder contrastar sus afirmaciones contra una aplicación arrancada. ¿Esa migración añadió de verdad la columna? ¿El job está realmente en la cola después de la petición? Eso no es adoración a la IA; es aplicar la regla más vieja que tenemos — no confíes, verifica — a un nuevo tipo de contribuidor. Los Evals extienden la misma honestidad a la propia salida del modelo: cuando la respuesta varía legítimamente entre ejecuciones, aseveras propiedades y límites en lugar de fingir que assertSame() zanja el asunto.

Ahora, el argumento más fuerte en mi contra, planteado con justicia. Uno: el requisito de PHP 8.4 es un muro real. Muchos equipos corren 8.2 u 8.3 en producción por razones que no tienen nada que ver con la pereza: imágenes del proveedor, congelaciones por compliance, esa extensión que nadie se atreve a recompilar. Para ellos, Pest 5 es una conversación de 2027, y no pasa nada. Dos: los frameworks de testing tienen memoria larga, y atornillarles herramientas para el flujo de trabajo de este año arriesga cargar peso muerto dentro de cinco. Puede que los Evals no sobrevivan en su forma actual. Aun así acepto ese riesgo, porque la alternativa — una historia de testing que ignora cómo se producen realmente los parches en mi equipo ahora mismo — me cuesta más este trimestre de lo que un plugin deprecado me costará después.

A lo que vuelvo una y otra vez es a que nada de esto cambia lo que es un test. Cambia quién lee la X roja. Cuando el lector es un humano, un fallo es feedback. Cuando el lector es un agente, un fallo es una barrera de contención — lo único que se interpone entre un parche que suena convencido y tu rama main. Prefiero un framework que se tome en serio ese segundo papel a uno que finge que seguimos en 2019.

Así que, colegas, dos preguntas que de verdad quiero que respondáis en los comentarios: ¿condicionarías un merge solo a los tests impactados, alguna vez — o la suite completa antes de main es innegociable en tu equipo, por buena que sea la selección? Y ¿ya has dejado a un asistente ejecutar tus tests sin supervisión, o el botón todavía lo pulsa un humano? Cuéntame dónde está tu línea, y por qué.