Unit test Il neofita del team deve effettuare unit test

Sto lavorando con un nuovo team che storicamente non ha effettuato QUALSIASI test unitario. Il mio obiettivo è che il team alla fine impieghi il TDD (Test Driven Development) come processo naturale. Ma dal momento che TDD è un cambiamento di mentalità così radicale per un team di test non unitari, ho pensato di iniziare con la scrittura di unit test dopo la codifica.

Qualcuno si è trovato in una situazione simile? Qual è un modo efficace per far sì che un team si senta a proprio agio con TDD quando non ha effettuato alcun test unitario? Ha senso farlo in un paio di passaggi? O dovremmo immergerci e affrontare tutti i dolori della crescita contemporaneamente ??

MODIFICARE

Solo per chiarimenti, non c'è nessuno nel team (diverso da me stesso) che abbia QUALSIASI esposizione / esperienza di test unitari. E stiamo pianificando di utilizzare la funzionalità di unit test integrata in Visual Studio.

Pratica su bug / difetti esistenti.

Questa è una situazione davvero difficile. Non ho mai raggiunto il TDD dal nulla prima, ma nella mia esperienza, far passare una squadra da nessun test unitario a scriverli in modo proattivo è stato un approccio molto "un passo alla volta".

In primo luogo, mettili comodi per scrivere test unitari e sapere davvero cosa sono e i loro benefici. Per i miei team, è stato meglio scrivere unit test per bug esistenti. Gli attuali bug nei sistemi hanno due cose che devi insegnare alle persone a scrivere bene i test unitari:

1. un presupposto e un postcondizionamento attesi
2. un risultato che attualmente non è quello che ci si aspetta e viola tale precondizione / postcondizione

Questo offre ai membri esempi concreti di pratica. Possono scrivere un test prima di correggere l'errore, in modo che fallisca. Quindi, possono correggere il codice in modo che passi e corregge il bug. Una volta che si sentono a proprio agio con questo, allora puoi ottenerli per il resto in modo che possano scrivere unit test in anticipo e quindi scrivere un nuovo codice per far passare i loro test.

Penso che il trucco sia quello di dare loro qualcosa da esercitarsi su dove ci sono chiare condizioni pre / post. Se i requisiti per i metodi sono confusi, è difficile per le persone TDD anche esperte sapere esattamente da dove iniziare. Fai un passo alla volta e ci arriverai. In bocca al lupo!

Sono riuscito a convincere tutta la mia azienda a passare al TDD. Non è stato facile, ma ne è valsa la pena: la qualità del codice è cresciuta dopo la transizione, e ora nessuno immagina di tornare ai tempi orribili della programmazione del cowboy.

1. Spiega, spiega, spiega. Non vuoi che il tuo team scriva dei test. Vuoi che il tuo team voglia scrivere test. Ciò significa che dovrebbero comprendere appieno il motivo per cui dovrebbero farlo, quali sono i vantaggi e come ciò renderà il loro lavoro molto più semplice. Rosso, verde, refattore , scrivendo un test di regressione come prova che è stato corretto un bug, ecc. Devi convincerli che tutto ha senso prima di chiedere loro di scrivere qualsiasi codice.

2. Scegli la cosa reale (prima test, quindi codice). Scrivere test dopo il codice difficilmente ha senso, poiché non si saprà mai se funzionano davvero (e le persone scrivono casi di buggy). La mia intuizione è che la quantità di sforzo è necessario passare da nessun test a test prima è molto meno di quello che è necessario andare formare nessun test attraverso il codice prima di test prima , in modo si può anche saltare il passaggio centrale.

3. Inizia con i test di regressione. Questi sono piuttosto semplici da capire e danno gratificazione immediata. Naturalmente, ciò presuppone che il codice sia correttamente modularizzato e facilmente testabile. In caso contrario, saltare questo passaggio.

4. Fai piccoli passi. TDD richiede del tempo per abituarsi e all'inizio può essere frustrante. Cerca di introdurre i test in un nuovo progetto o componente, idealmente: qualcosa di non molto importante. Volete evitare a tutti i costi la situazione in cui c'è qualcosa di veramente importante da fare molto rapidamente e i programmatori sentono che TDD si sta mettendo in mezzo.

5. Quando il team inizia a sentirsi a proprio agio, tutte le nuove funzionalità sono scritte in modo TDD. Questo dipende dalle dimensioni del tuo progetto, ma dopo qualche tempo dovresti ottenere una copertura abbastanza buona, con solo alcune parti legacy del tuo progetto scritte alla vecchia maniera.

6. A questo punto, il team dovrebbe già comprendere e abbracciare il TDD e le cose legacy (non TDD) dovrebbero essere considerate difficili e fastidiose con cui lavorare. Falla refactored: la maggior parte delle persone lo farà con piacere.

Alcuni altri punti importanti:

• Assicurati di utilizzare il miglior framework di test disponibile. Sarà molto più difficile convincere le persone a fare TDD se devono interagire con una biblioteca mal scritta.

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

• Installa alcuni software di integrazione continua, in modo che i test non funzionanti vengano trovati immediatamente.

Un modo per familiarizzare con TDD è scrivere prima i test di integrazione. Introdurre in seguito cuciture di prova e test di unità reali.

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 magari riprogettare per introdurre le cuciture di prova. Ma come si può rifattorizzare o riprogettare in modo sicuro se non si dispone di una copertura di prova di alcun tipo?

I test di integrazione possono inizialmente fornirti tale copertura. Ogni volta che si verifica una regressione o un problema di produzione, risolverlo nel codice e coprirlo con un test. Una volta che si dispone di una rete di sicurezza sufficiente fornita da tali test, è possibile introdurre test unitari di componenti e / o classi del sistema più finemente isolati.

TDD è molto difficile da implementare e non è sempre l'opzione migliore per ogni team di sviluppo. Nel mio precedente lavoro, il team era fortemente focalizzato sul TDD. Il nostro modello di sviluppo è stato interamente TDD utilizzando l'approccio di sviluppo agile. Il test è stato effettuato tramite test unitari di Visual Studio.

Se uno sviluppatore non scrivesse alcun test unitario per la sua caratteristica, si troverebbero nei guai con il responsabile tecnico. Inoltre, se qualcuno effettua il check-in di una build non funzionante o di qualsiasi unit test, lo sviluppatore dovrebbe risolvere tutti i problemi e aggiungere un $ 1 al barattolo di denaro del team.

Solo una piccola cosa da aggiungere, visualizzare il processo. Esegui automaticamente i test di integrazione continua e verifica la copertura del codice. Elenca i moduli testati più completi su alcune pagine iniziali che tutti possono vedere. Ciò dovrebbe far andare la competizione a squadre.

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

Sono stato in team che non hanno fatto alcun test unitario ma è stato introdotto ed è diventato quasi comune avere dei test ora. Suggerirei di esplorare in che misura il tuo team comprende le basi del test unitario e quali strumenti vuoi mettere qui?

Nel mio caso stava introducendo nUnit per alcuni codici .Net che erano un mix di logica aziendale, interfaccia utente e funzionalità back-end. Suggerirei di vedere se ci sono alcune persone che sono più intenzionate a volerci più di altre, in modo che un paio di persone nel team lo capiscano e che possano diffondersi un po 'meglio del rovescio in cui si tenta di ottenere tutti per saltare su questo. Facendo in modo che alcuni lo facciano bene prima, ciò consente un po 'di allenamento incrociato in modo che coloro che lo raccolgono possano essere testati su quanto bene possono insegnarlo a qualcun altro.

Un altro punto è considerare la possibilità di coinvolgere coloro che hanno più competenze per provare a mostrarlo in una certa misura. Thoughtworks è stato introdotto dove lavoro per mostrarci alcune cose che alcune di esse sono state ampiamente adottate e altre parti non così tanto, ma penso che sarebbe vero nella maggior parte dei luoghi.