Test delle unità Il team di principianti deve eseguire il test dell'unità

Esercitati su bug / difetti esistenti

Questa è una situazione davvero difficile. Non sono mai andato fino a TDD da niente prima, ma nella mia esperienza, far passare una squadra da nessun test unitario a scriverlo in modo proattivo è stato un approccio "un passo alla volta".

In primo luogo, mettili a loro agio nel test delle unità di scrittura e sapendo davvero quali sono e i loro benefici. Per i miei team, è meglio scrivere test unitari per bug esistenti. Gli attuali bug nei sistemi hanno due cose che devi insegnare alle persone a scrivere bene i test unitari:

1. una precondizione e post-prenotazione attese
2. un risultato che al momento non è quello che ci si aspetta e viola quella precondizione / post-condizionale

Ciò fornisce ai membri esempi pratici concreti. Possono scrivere un test prima di correggere il bug, in modo che non funzioni. Quindi, possono correggere il codice in modo che passi e corregga il bug. Una volta che si sentono a proprio agio con questo, puoi ottenerli per il resto in modo che possano scrivere test unitari senza codice in anticipo e quindi scrivere un nuovo codice per far passare i test.

Penso che il trucco sia dare loro qualcosa per esercitarsi su dove ci sono chiare modalità pre / post-condizioni. Se i requisiti per i metodi sono confusi, è difficile per le persone con esperienza di TDD anche sapere esattamente da dove iniziare. Fai un passo alla volta e ci arriverai. Buona fortuna!

Sono riuscito a convincere la mia intera azienda a passare a TDD. Non è stato facile, ma ne è valsa la pena: la qualità del codice è aumentata dopo la transizione, e ora nessuno immagina di tornare agli orribili tempi di codifica dei cowboy.

1. Spiega, spiega, spiega. Non vuoi che la tua squadra scriva test. Vuoi che il tuo team voglia di scrivere test. Ciò significa che dovrebbero comprendere pienamente perché dovrebbero farlo, quali sono i vantaggi e come questo renderà il loro lavoro molto più facile. Red, Green, Refactor , scrivendo un test di regressione come prova che un bug è stato corretto, ecc. Devi convincerli che tutto ha senso prima di chiedere loro di scrivere qualsiasi codice.

2. Vai per la cosa reale (primi test, poi codice). Scrivere test dopo il codice non ha alcun senso, in quanto non si saprà mai se funzionano (e le persone scrivono casi di test errati). La mia intuizione è che la quantità di sforzo necessaria per passare da nessun test a prima prova è molto inferiore a quella necessaria per diventare nessun test tramite prima il codice a prima il test , quindi puoi anche saltare il passaggio intermedio.

3. Inizia con i test di regressione. Questi sono abbastanza semplici da capire e danno una gratificazione immediata. Ovviamente, questo presuppone che il codice sia correttamente modularizzato e facilmente verificabile. In caso contrario, salta questo passaggio.

4. Fai piccoli passi. TDD richiede un po 'di tempo per abituarsi e potrebbe essere frustrante all'inizio. Cerca di introdurre test in un nuovo progetto o componente, idealmente: qualcosa di non molto importante. Vuoi evitare a tutti i costi la situazione quando c'è qualcosa di veramente importante da fare molto velocemente e i programmatori sentono che il TDD sta intralciando.

5. Quando il team inizia a stare tranquillo, ha tutte le nuove funzionalità scritte in modo TDD. Questo dipende dalla dimensione del tuo progetto, ma dopo un po 'di tempo dovresti ottenere una copertura abbastanza buona, con solo alcune parti legacy del tuo progetto scritte nel vecchio modo.

6. A questo punto, il team dovrebbe già comprendere e abbracciare TDD, e la roba legacy (non TDD) dovrebbe essere considerata difficile e fastidiosa con cui lavorare. Scaricalo nuovamente: la maggior parte delle persone lo farà con piacere.

Alcuni altri punti importanti:

• Assicurati di utilizzare la migliore struttura di test disponibile. Sarà molto più difficile convincere le persone a fare TDD se devono interagire con una libreria che è scritta male.

• Assicurati che i test siano facili da eseguire e non impieghi troppo tempo per terminare (o imbrogliare, ad esempio utilizzando un db in memoria per i test).

• Imposta alcuni software di integrazione continua, in modo da trovare immediatamente i test non funzionanti.

Un modo per sentirsi a proprio agio con TDD è scrivere per primi test di integrazione. Introduci i giunti di prova e veri test unitari più tardi.

Il problema con la scrittura di unit test dopo la codifica è che il codice potrebbe non essere necessariamente ben progettato per essere testabile . Potrebbe essere necessario eseguire alcuni refactoring o forse riprogettazione per introdurre le cuciture di prova. Ma come puoi refactoring o re-design in sicurezza se non hai copertura di test di qualsiasi tipo?

I test di integrazione possono darti quella copertura inizialmente. Ogni volta che si verifica una regressione o un problema di produzione, correggerlo nel codice e coprire quel codice con un test. Una volta che hai abbastanza di una rete di sicurezza fornita da tali test, puoi introdurre i test unitari di più componenti e / o classi isolate a grana fine e / o classi del tuo sistema.

Il TDD è molto difficile da implementare e non è sempre l'opzione migliore per ogni team di sviluppo. Nel mio precedente lavoro, il team era strongmente focalizzato su TDD. Il nostro modello di sviluppo è stato interamente TDD utilizzando l'approccio di sviluppo agile. Il test è stato eseguito tramite i test di unità di Visual Studio.

Se uno sviluppatore non ha scritto alcun test unitario per la sua caratteristica, si troverebbe nei guai con il lead tecnico. Inoltre, se qualcuno effettua il check-in di una build fallita o di un qualsiasi test unitario, lo sviluppatore dovrebbe risolvere tutti i problemi e aggiungere $ 1 al vaso del team money.

Solo una piccola cosa da aggiungere, visualizza il processo. Effettuare automaticamente i test di integrazione continui e verificare la copertura del codice. Elenca i moduli testati più completi su qualche pagina iniziale che tutti possono vedere. Questo dovrebbe far andare la competizione a squadre.

Sono stato in team che non hanno effettuato test di unità, ma è stato introdotto ed è diventato quasi normale avere alcuni test ora. Ti suggerirei di esplorare in che misura il tuo team comprende le basi dei test unitari e quali strumenti vuoi portare qui?

Nel mio caso è stato introdotto in nUnit per un certo codice .Net che era un mix di business logic, interfaccia utente e funzionalità di back-end. Suggerirei di vedere se ci sono alcune persone che sono più intenzionate a volerlo fare più di altre in modo che un paio di persone nel team lo capiscano e possa diffondersi un po 'meglio del rovescio della medaglia dove si cerca di ottenere tutti per saltare su questo. Facendo in modo che alcuni lo facciano per primi, questo consente un po 'di allenamento incrociato in modo che quelli che lo raccolgono possano essere testati su quanto possono insegnarlo a qualcun altro.

Un altro punto è considerare di coinvolgere coloro che hanno più esperienza per cercare di mostrare questo in una certa misura. Thoughtworks è stato portato dove lavoro per mostrarci alcune cose che alcune sono state ampiamente adottate e altre parti non così tanto, ma penso che sarebbe vero nella maggior parte dei luoghi.

Sono passato da nessuna esperienza JUnit direttamente a TDD, e l'esperienza ha reso il valore di TDD inequivocabilmente evidente. Sono diventato così grato per i test unitari che sono diventato rapidamente un evangelista per l'approccio