Manovra Kluever: correggi i bug in due commit e prova che funzionano

Correggi ogni bug in due commit: prima aggiungi un test che registra il comportamento errato e che passa, poi inserisci la patch e modifichi il test perché esprima il comportamento corretto. Così dimostri la correzione e la CI resta verde a ogni commit¹.

Commit 1: scrivi un test che riproduce il bug e che passa con il codice attuale, proprio perché fotografa l’errore. Commit 2: sistemi il codice e cambi il test per riflettere il comportamento voluto. Due effetti: hai una prova documentata che la patch risolve il problema e la pipeline passa a ogni passaggio della storia. Il post spiega perché un singolo commit con test e fix insieme può ingannare se il test passava già prima¹.

L’articolo apre con un esempio: la funzione add somma a + b + 1, che è sbagliato. Nel primo commit si aggiunge un test che registra il comportamento errato, aspettandosi 5 da add(2, 2). Nel secondo commit si toglie l’off-by-one dalla funzione, che torna a a + b, e si “flippa” il test per aspettarsi 4. La coppia di commit mostra la rottura e la riparazione senza ambiguità, e la CI resta verde perché ogni commit è coerente con i test che contiene¹.

Poi il caso sottile. Un controllo di età calcola solo la differenza tra gli anni. A ottobre 2026, chi è nato a dicembre 2008 non ha ancora 18 anni. Una patch superficiale cambia solo l’operatore nella funzione can_access, da “18 <=” a “18 <”. Ma il problema sta nel calcolo dell’età, non nella soglia. Quel “fix” non corregge nulla, e il test proposto passa sia prima sia dopo la modifica. È il falso positivo che la manovra vuole evitare¹.

Per inquadrare bene il bug, il post propone un test mirato: nato il 31 dicembre 2008, oggi 1 gennaio 2026. Nel primo commit si scrive il test che, con il codice corrente, asserisce il comportamento errato. Nel secondo commit si corregge il calcolo usando dateutil.relativedelta e si ritorna .years. Il test viene ribaltato perché ora, con la correzione, quell’utente non deve avere accesso. La sequenza rende evidente l’errore originale e la sua soluzione¹.

C’è anche una prassi operativa per il tracciamento. L’autore suggerisce di aprire un bug nel tracker, citarlo nel primo commit e chiudere il ticket nel secondo. Un esempio: nel test del commit 1 un commento “FIXME: bug #1729”, nel commit 2 un messaggio “fixes: #1729” insieme alla patch e all’aggiornamento del test. Chi legge la storia vede il caso che passa perché cattura il comportamento errato, la correzione che lo ribalta e il collegamento al ticket¹.

Se test e fix stanno nello stesso commit, rischi di non vedere che il test non intercetta il bug. Con due commit separati, il primo dimostra l’errore perché il test passa pur essendo sbagliato, il secondo lo corregge e aggiorna l’asserzione: una prova minima e sufficiente, anche quando il difetto è meno ovvio del classico off-by-one¹.

Il nome viene da chi l’ha insegnata all’autore, Kurt Kluever. Lui la chiama anche “terrible tests”: test che affermano consapevolmente qualcosa di sbagliato per inchiodare il bug prima di curarlo¹.