Buona storia di test unitario per un allenamento di prova unitario [chiuso]

Personalmente, apprezzo molto i test unitari sul punto di creazione, nella loro capacità di costringere lo sviluppatore a pensare al codice che hanno scritto e di convalidare il modo in cui pensano che il loro codice si comporti.

Quando un test di un'unità storica si interrompe, nella mia esperienza di solito è dovuto a una funzionalità prevista o al cambiamento di progettazione e il test dell'unità deve essere riscritto per riflettere il nuovo codice. Anche se le rare (forse 1 su 20) occasioni in cui hanno catturato un bug in fretta sono preziose, l'atto di costringere uno sviluppatore a dimostrare che il loro nuovo codice si comporta nel modo in cui lo pensano aggiunge molto più valore al codice base.

IMHO il valore dei test unitari può essere compreso più chiaramente ogni volta che devi creare librerie riutilizzabili, specialmente quando queste librerie sono generiche, con poche o nessuna dipendenza da altre parti del sistema.

Pensa a una libreria matematica (ad esempio, per operazioni vettoriali o matriciali, per grafici o per calcoli grafici). Quel genere di cose è spesso un buon test unitario, e dovrebbe essere chiaro che, una volta che una tale lib viene usata in una dozzina di programmi o giù di lì, cambiare qualcosa internamente in quel lib vorrà dire che dovrai testare molti più programmi di nuovo, contrario alla situazione se disponi di una suite di test unitaria disponibile con una copertura elevata.

Ci sono anche alcuni buoni video di Brett L. Schuchert, che mostrano la codifica live di TDD, per esempio, questo per C ++ o questo per Java , forse li trovi utili.

Sembra che tu stia cercando di "vendere" i test unitari nella tua azienda. (Buono per te!)

Ho intenzione di rischiare di essere odiato qui, ma suona come se tu potessi non farlo essere al 100% chiari su tutti i vantaggi dei test di unità di scrittura. Come altro le risposte hanno sottolineato, ci sono molte ragioni per cui i test unitari sono estremamente utile (a volte anche necessario) oltre a catturare bug che il compilatore non ha catturato.

Suggerisco di familiarizzare con tutti i vantaggi e di progettare la mia demo di conseguenza.

Ecco alcune cose veloci di cui vorrei parlare / demo (non in un ordine speciale):

Convalida rapida che l'unità di codice funziona senza doverla effettivamente eseguire nel suo ambiente previsto. Questo è estremamente cruciale quando ci vogliono 5 minuti per costruire il tuo progetto, 10 minuti per dispiegarlo e mezz'ora per provare a trova lo scenario quando il codice viene effettivamente eseguito per verificare che funzioni ".

Convalida del codice che sarebbe estremamente difficile da testare nel suo intento ambiente. Un'enorme percentuale del codice che scriviamo sta gestendo le condizioni di errore o condizioni che si verificano solo in alcune strane circostanze. Queste condizioni sono molto difficili da riprodurre nella vita reale, quindi richiedono un'attenzione speciale testare.

Convalida del codice "library". Se stai scrivendo il codice che altri consumano, il tuo solo modo di convalidare sarebbe scrivere un altro "progetto" che consuma e guida esso. I test unitari ti danno la certezza che il tuo codice funzioni senza averlo utilizzare un progetto che guida il tuo codice per testarlo o per scrivere un'app "tester" te stesso.

TDD. Test Driven Development è un modo di pensare abbastanza nuovo test unitari. Quando si esercitano gli sviluppatori TDD, scrivere prima i test, quindi il codice dopo. TDD può migliorare il tuo codice scrivendo solo codice che soddisfi il superamento dei test. C'è molto dibattito su questo argomento e io stesso l'ho usato con estremo successo in determinate situazioni, ma non così con successo in altri (IMHO dipendente dal contesto).

I test documentano il tuo codice. Molte volte i test sono la documentazione più aggiornata su come dovrebbe comportarsi il tuo codice. Quante volte lo cerchi già pezzo di codice esistente che esercita una classe / metodo solo per vedere come sei dovrebbe usarlo? Beh, i test unitari ti danno proprio questo.

Rottura del codice. Sì, i test unitari catturano i bug. Tuttavia lo trovo più spesso catturare bug durante lo sviluppo. Scrivo il codice, poi mi giro per scrivere il test e questa è la fase in cui prendo più errori.

Sono sicuro che ci sono altre cose da menzionare qui, quindi dovresti fare più ricerche prima del tuo allenamento Un'altra cosa. È difficile trovare esempi durante i test unitari 'ha salvato la giornata in grande stile' perché cattura i bug durante lo sviluppo e molto silenziosamente la maggior parte delle volte. Tu capisci davvero i loro benefici quando li hai scritti per un po 'per vedere come salvano la giornata (su base giornaliera).

Vorrei confrontarli con l'esercizio. È difficile trovare un caso ogni giorno l'esercizio ha salvato qualcuno dall'avere un cancro o un infarto. Ma sai in fondo che è necessario vivere una vita lunga e sana.

(sì, sto rispondendo alla mia stessa domanda - mi è appena capitato di ricordare un buon esempio)

Ricordo di aver trovato e interrotto alcuni complicati loop di riferimento dei puntatori intelligenti C ++ con la combinazione di unit test + valgrind.

La visualizzazione di alcune perdite nei test unitari (= limitati) facilita la diagnosi di chi detiene il riferimento imprevisto rispetto al codice completo in esecuzione. (In questo caso, era una relazione genitore / figlio con entrambi che necessitano di un puntatore condiviso sull'altro. Rotto usando weak_ptr)