Aggiungi un test unitario per ogni nuovo bug

Questo è abbastanza comune. Lo usiamo nel nostro team. Per ogni difetto di produzione, lo sviluppatore deve aggiungere una nota sulla causa principale del problema, aggiungere un test dell'unità in errore e aggiungere un'analisi dell'impatto del test prima che il ticket possa essere trasferito allo stato di sviluppo per verificare il codice.

Il test dell'unità guasta deve passare prima che possiamo spingere il codice in produzione.

Non penso che questo abbia un nome specifico tranne quel generale "test di regressione". Questo è molto utile e abbiamo iniziato a vedere un aumento della qualità del prodotto dopo che abbiamo iniziato a seguire questo processo.

Assolutamente!

Se puoi essere d'accordo sul fatto che i test unitari sono una buona cosa, allora ti renderai conto che se c'è un bug c'è un test unitario mancante che copre quel percorso di codice.

Quindi, ciò che dovrebbe accadere è scrivere un test unitario che mostri il bug esistente, correggere il bug effettivo, quindi il test unitario passerà.

Se non hai affatto test unitari, allora questo può essere un buon modo per iniziare a introdurre i test unitari a un progetto.

La tecnica è uno sviluppo basato sui test. La prossima volta non sarà in grado di individuare un bug simile, sebbene la suite di test ripetibili sia sempre utile. Il punto è che puoi dimostrare di aver isolato ciò che è sbagliato nel codice, di averlo dimostrato che è sbagliato, risolto, provato che la correzione è corretta.

C'è una citazione che non riesco a ricordare o trovare, ma grosso modo è: "Ogni bug è un test non ancora scritto."

Cercare di venderlo come test di regressione è una battaglia persa, IMHO. Dato che raramente queste cose catturano un bug ripetuto, la maggior parte degli sviluppatori dirà semplicemente "Perché preoccuparsi, quando posso semplicemente sistemarlo?"