Quando il verifier boccia i tuoi test verdi

In breve. La stessa suite di 14 test passava tutta in locale e ne falliva metà nell'ambiente del verifier: 7 PASS contro 7 FAIL. Da lì ho imparato la regola che ora applico ovunque: il "verde" dichiarato da chi esegue non vale niente finché non è riprodotto nell'ambiente di chi verifica. I numeri vengono dal corpo della PR #323 del framework (review indipendente F1–F4 arrivata con la PR #322). Pubblicato il 5 ottobre 2026.

Quattordici verdi qui, sette rossi lì

Il caso è semplice da raccontare e scomodo da digerire. Una correzione al meccanismo di verifica del framework — la T1, "contained verification" — aveva la sua suite verde: 14 test passati su 14 nell'ambiente ordinario di sviluppo. Poi qualcuno ha eseguito lo stesso reproducer nell'ambiente del verifier, quello che certifica davvero, e il risultato è stato 7 PASS e 7 FAIL. Stessi test, stesso codice, due ambienti, due verdetti.

La prima reazione è dare la colpa ai test fragili. La seconda, quella giusta, è dare la colpa all'ambiente implicito: i 14 verdi dipendevano da cose che in locale c'erano sempre e nel verifier no. La directory di lavoro del proprietario usata come default, la revisione di codice effettivamente caricata mai riletta, i criteri di accettazione legati a componenti di runtime mai dichiarati. Niente di tutto questo era nei test: era sotto i test.

Perché l'ambiente del verifier non era il mio

La correzione che ha chiuso il caso, descritta nel corpo della PR #323, dice esattamente dove stava la differenza. Quattro punti, nessuno sul codice di prodotto in senso stretto, tutti sul legame fra prova e ambiente: ogni criterio legato esplicitamente ai componenti di runtime e di release che lo misurano; identità del processo e revisione caricata rilette davvero, non presunte; sonde eseguite senza la directory del proprietario come default nascosto; serializzazione degli scrittori concorrenti con lock di sistema invece che con la speranza.

Il punto che mi porto a casa è il primo: una prova senza ambiente dichiarato non è una prova, è un racconto. "14 PASS" senza dire dove, con cosa caricato e contro quali criteri è una frase a metà. Il verifier l'ha completata nel modo peggiore possibile, fallendo.

Cosa ha chiuso il caso, con i numeri

Dopo la correzione, la stessa suite gira 3.216 passati e 2 saltati (pre-esistenti) sia in ordinario sia nel checkout contenuto del verifier con la sua installazione pulita, più typecheck pulito; il reproducer originale passa 14 su 14; le regressioni dedicate passano 62 su 62; i golden di selettore e misura passano 96 su 96; la CI esterna è verde sullo stesso SHA. Una review indipendente post-merge, in sola lettura, ha dato PASS con F1–F4 esplicitamente risolti e nessun rilievo bloccante.

E qui viene la parte onesta, quella che mi piace di più: il verdetto T1 dice PASS "solo per il tentativo contenuto". Non certifica tutto, certifica il perimetro provato. È lo stesso principio dell'ambiente: un verde senza perimetro dichiarato è un racconto, anche quando i numeri sono grossi come 3.216.

Cosa faccio adesso prima di dire "verde"

Tre regole, in ordine. Primo: mai dichiarare un risultato senza nominare l'ambiente in cui è stato ottenuto — directory, revisione caricata, criteri misurati. Secondo: se qualcun altro deve certificare, il suo ambiente viene prima del mio: eseguo lì, o non dichiaro. Terzo: il verdetto nomina sempre il suo perimetro, come quel "solo per il tentativo contenuto" che vale più di mille verdi generici.

Sui sistemi che imparano dagli errori ho scritto dei marginal gains delle macchine: questo pezzo è il prerequisito, perché un sistema impara solo dagli errori che riesce a riprodurre. E sulla fabbrica che ripara il software mentre dormiamo e sul controllo progettato ho raccontato il resto del loop. Ma tutto il loop poggia su questa regola banale: il verde conta solo dove verifica chi verifica.

Domande frequenti

I test erano sbagliati?

No: erano incompleti. Passavano perché l'ambiente locale forniva gratis ciò che non dichiaravano. La correzione non ha riscritto i test per farli passare, ha legato ogni criterio ai suoi componenti e rimosso i default nascosti.

Basta eseguire tutto nella CI?

È necessario ma non sufficiente: la CI è un ambiente come un altro, e va dichiarato anche lei. Quello che conta è che l'ambiente di chi certifica sia lo stesso — o un gemello provato — di quello dove il risultato è stato dichiarato.

Perché citare i numeri esatti?

Perché senza sono un altro racconto: 7 PASS su 7 FAIL contro 14 PASS prima, 3.216 passati con 2 saltati pre-esistenti dopo, 62 su 62 le regressioni, 96 su 96 i golden. Tutti riportati nel corpo della PR #323 del framework, verificabili da chi ha accesso al repository.