I test di regressione descrivono intenzioni, non il comportamento reale

Stack Overflow Blog avverte su dove si nascondono molte rotture: nei comportamenti che il software accumula in produzione e che nessuno ha mai scritto nei test¹.

L’equivoco è chiaro: i test di regressione, per lo più, raccontano le intenzioni degli sviluppatori, non ciò che il sistema fa davvero dopo anni di uso reale¹. I test nascono accanto a una feature. Dicono cosa dovrebbe accadere: questa funzione restituisce quello, questo endpoint rifiuta input non validi. Sono utili. Ma riflettono ciò che si voleva ottenere, non per forza ciò che, col tempo, il sistema ha iniziato a fare.

Con gli anni ogni applicazione sviluppa un secondo strato di comportamento. Non pianificato. Non documentato. Piccole stranezze, edge case ricorrenti, default mai ripensati. Utenti e servizi interni finiscono per appoggiarsi a quei dettagli, in silenzio. Nessuno li ha promessi. Nessuno li ha descritti nei test. Eppure quelle dipendenze esistono¹.

Qui nascono molte regressioni insidiose, spiega l’articolo¹. Non rompi una regola scritta. Rompi un’abitudine emersa nel tempo, un comportamento osservabile che non compare in nessuna specifica. Cambi quel dettaglio, e qualcosa altrove smette di funzionare.

Il quadro ha un nome: Hyrum’s Law, da Hyrum Wright in Google. Il succo è netto, e conta per chi costruisce API e integrazioni: se abbastanza persone usano la tua API, ogni comportamento osservabile diventa la dipendenza di qualcuno¹. Non solo il contratto documentato. Tutto ciò che si vede dall’esterno.

Esempio ipotetico: una API restituisce un elenco in ordine alfabetico perché così è capitato in implementazione. Nessuna specifica lo dice. Un team a valle si affida a quell’ordine. Un giorno l’owner cambia l’ordinamento in base alla data. Nessun test di regressione fallisce, perché i test coprono solo i campi e i codici di risposta. Ma in produzione si spacca un flusso che, di fatto, dipendeva da quell’ordine.

Per colmare il divario serve una seconda lente: test che fotografano il comportamento com’è, non solo come dovrebbe essere¹. L’idea proposta è semplice: osservare ciò che gli utenti vedono e di cui si sono, nel tempo, fidati. Catturarlo in test che proteggano quel contratto di fatto. Non si tratta di abolire i test accanto alle feature. Si tratta di affiancarli con guardrail sull’osservabile¹.

Questo cambio di prospettiva sposta anche la definizione di “contratto”. Per molti, il contratto non è la pagina di documentazione. È ciò che la produzione mostra ogni giorno. Un default rimasto lì, un ordine di campi, il testo di un errore. Se esiste in modo stabile e visibile, qualcuno potrebbe farci affidamento¹.

La conseguenza è operativa: la copertura va estesa a ciò che il sistema fa oggi, non solo a ciò che i test iniziali dichiaravano¹. Il beneficio non è solo evitare regressioni. È rendere esplicite, e quindi governabili, le promesse di fatto che il software emette ogni volta che va online.