Come avviare il test dell'unità o TDD?

Question

Ho letto un sacco di post che mi hanno convinto che avrei dovuto iniziare a scrivere unit test, ho anche iniziato a usare dependency injection (Unity) per il più semplice beffeggiamento, ma non sono ancora abbastanza sicuro su quale fase dovrei iniziare a scrivere l'unità verifica e fa il motto, e come o dove iniziare.

Il modo preferito è scrivere i test di unità prima dei metodi come descritto nella metodologia TDD?

Esiste una metodologia o una modalità diversa per il test dell'unità?

Answer 1

prova prima/test dopo:

Si deve rilevare che 'test prima' come parte del TDD è altrettanto (se non di più) a che fare con il design in quanto è a che fare con unit testing . È una tecnica di sviluppo del software a sé stante: la scrittura dei risultati dei test è un costante perfezionamento del design.

In una nota a parte: se c'è un vantaggio significativo per TDD da una pura prospettiva di testing unitario, è che è molto più difficile (anche se non impossibile) scrivere un test che è sbagliato quando si fa TDD. Se si scrive il test in anticipo, è necessario che sia sempre in errore perché la logica richiesta per eseguire il test di prova non esiste ancora.Se in seguito si scrive il test, la logica dovrebbe essere, ma se il test è sottoposto a un bug o sta testando la cosa sbagliata, potrebbe passare a prescindere.

I.e. se scrivi prima un test negativo, potresti ricevere una luce verde quando ti aspetti un rosso (quindi sai che il test è sbagliato). Se in seguito scrivi un test negativo, riceverai una luce verde quando ti aspetteresti un green (inconsapevole del test negativo).

Libri

Il libro unit testing pragmatica è la pena dare un'occhiata, come è Roy Osherove di "The Art of Unit Testing". Il libro pragmatico si focalizza più strettamente sui diversi tipi di input di test che è possibile provare a trovare bug, mentre TAOUT copre una più ampia gamma di argomenti come test double, strategie, manutenibilità, ecc. O prenotare è buono; dipende da ciò che vuoi da esso.

Inoltre, ecco uno link to a talk Roy Osherove did on unit testing. Vale la pena fare un orologio (così come alcuni dei video di revisione dei test che ha registrato, in quanto sottolinea vari problemi e cose da fare e cose da fare insieme ai motivi per cui).

come avviare

Non c'è niente di meglio che la scrittura di codice. Trova una classe abbastanza semplice che non faccia riferimento a molto altro. Quindi, inizia a scrivere alcuni test.

Chiediti sempre "cosa voglio provare e provare con questo test?" prima di scriverlo, quindi dargli un nome decente (di solito coinvolgendo il metodo chiamato, lo scenario e il risultato atteso, ad esempio in una pila: "Pop WhenStackIsEmpty ThrowsException").

Pensa a tutti gli input che puoi lanciare, combinazioni diverse di metodi che possono dare risultati interessanti e così via.

Answer 2

Steve Sanderson ha una buona conoscenza delle best practice TDD.

http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/

Inoltre, c'è una grande serie di tutorial per fare un progetto MVC ASP.net che discute un sacco principi TDD (se non vi occupate di apprendimento ASP.net MVC lungo la strada) http://www.asp.net/learn/mvc-videos/ sguardo per la serie "Storefront" in fondo alla pagina.

MOQ sembra essere il quadro di scherno caldo ultimamente, si consiglia di guardare in quello pure

In sintesi, provare a scrivere un test per convalidare qualcosa you'r cercando di archivio, quindi implementare il codice per fallo funzionare.

Il modello è noto come Rosso - Verde - Refactor. Fai del tuo meglio per minimizzare le dipendenze in modo che i test possano concentrarsi su un componente.

Personalmente, io uso i test dell'unità di Visual Studio. Io non sono uno sviluppatore TDD hardcore, ma quello che mi piace fare è questo:

1. Creare un nuovo progetto e definire alcune delle classi fondamentali in base alla progettazione del sistema (in questo modo posso almeno avere un po ' intellisense)
2. creare un progetto di unit test e iniziare a scrivere unit test per soddisfare la funzionalità che sto cercando di implementare.
3. farli fallire
4. farli passare (implementare)
5. Refactor
6. Ripetere, cercare di rendere il test più rigorosi o creare più test fino a quando sento la sua solida.

Mi sento anche molto utile aggiungere funzionalità su un code code esistente. Se vuoi aggiungere qualche nuova funzionalità, prima crea il test unitario per ciò che desideri aggiungere, passa attraverso il codice per vedere cosa devi cambiare, quindi passa attraverso il processo TDD.

Answer 3

Se sei curioso di testare l'unità, il modo migliore per impararlo è provarlo. Probabilmente inizierai a scrivere test di integrazione all'inizio, ma va bene. Quando sembrano troppo difficili da mantenere o troppo lavoro da scrivere, leggi di più su che tipo di test ci sono (unità, funzionalità, integrazione) e cerca di imparare la differenza.

Se sei interessato a iniziare con TDD, lo zio Bob è una buona fonte. Partlyulary this.

Altro su Unità di prova

assicurarsi di ottenere i risultati dei test coerenti.Eseguire ripetutamente lo stesso test dovrebbe restituire gli stessi risultati in modo coerente.

I test non dovrebbero richiedere la configurazione.

L'ordine di test non dovrebbe avere importanza. Ciò significa che esecuzioni di test parziali possono funzionare correttamente. Inoltre, se si tiene a mente questa filosofia di progettazione, sarà probabilmente utile nella creazione del test.

Ricordare che qualsiasi test è migliore di nessun test. La difficoltà si può trovare nella stesura di buoni test unitari puliti che promuovono la facilità di creazione e manutenzione. Più difficile sarà il quadro di test, maggiore sarà l'opposizione ad impiegarlo. Il test è tuo amico.

Answer 4

Leggi Pragmatic Unit Testing in C# with NUnit. Ha informazioni complete su come iniziare a scrivere test e strutturare il codice per renderlo più facile da testare.

Answer 5

Sì, il preferito modo di fare TDD è quello di scrivere il primo test (come implica il nome Test-Driven Development). Quando inizi con TDD può essere difficile sapere da dove iniziare a scrivere i test, quindi suggerirei di essere pragmatico al riguardo. Dopotutto, la parte più importante del nostro lavoro consiste nel fornire codice funzionante, non tanto sul modo in cui il codice è stato realizzato.

Quindi è possibile iniziare scrivendo i test per il codice esistente. Una volta capito come sono strutturati i test unitari, quali sembrano fare un buon lavoro e quelli che non sembrano così divini, allora sarà più facile immergersi maggiormente nell'approccio test-first. Ho scoperto che scrivo prima i test in misura maggiore con il passare del tempo. Diventa semplicemente più naturale con maggiore esperienza.

Answer 6

Se non hai ancora scritto test di unità, scegli solo alcune classi e inizia a scrivere i test di unità, e continua a lavorare sullo sviluppo di più test di unità.

Man mano che si acquisisce esperienza, è possibile iniziare a prendere in giro il database, ad esempio, utilizzando il framework Unity, ma, vorrei suggerire di iniziare semplicemente e acquisire esperienza prima di fare questo salto.

Una volta che hai dimestichezza con come scrivere i test delle unità, puoi provare a fare TDD.

Answer 7

In C# e Visual Studio Trovo seguente procedura molto utile:

1. Pensate! Fai un piccolo progetto in anticipo. È necessario avere un'immagine chiara di quali classi sono necessarie e di come gli oggetti devono essere in relazione tra loro. Concentrati solo su una classe/oggetto (la classe/oggetto che vuoi implementare) e una relazione. Altrimenti si finisce con un design troppo pesante. Spesso finisco con schizzi multipli (solo poche scatole e frecce) su un foglio di carta di ricambio.

2. Creare la classe nel codice di produzione e denominarla in modo appropriato.

3. Scegliere un comportamento della classe che si desidera implementare e creare un metodo di stub per esso. Con lo studio visivo creare matrici di metodi vuoti è un gioco da ragazzi.

4. Scrivere un test per questo. Pertanto è necessario inizializzare quell'oggetto, chiamare il metodo e formulare un'asserzione per verificare il risultato. Nel caso più semplice l'asserzione richiede un altro metodo stub o una proprietà nel codice di produzione.

5. Compilare e lasciare che il test runner mostri la barra rossa!

6. Codificare il comportamento richiesto nel codice di produzione per visualizzare la barra verde.

7. Passare al comportamento successivo.

Per questa procedura due cose sono molto importanti:

• Hai bisogno di un quadro chiaro cosa si vuole e come la classe/oggetto dovrebbe essere simile. Almeno passa un po 'di tempo.
• Pensa ai comportamenti della classe/oggetto. Ciò renderà i test e il codice di produzione incentrati sul comportamento, che è un approccio molto naturale per pensare a classi/oggetti.

Test prima o non testare prima?

Trovo solitamente più difficile il retrofitting dei test sul codice di produzione esistente. Nella maggior parte dei casi ciò è dovuto a dipendenze intrecciate ad altri oggetti, quando l'oggetto sottoposto a test deve essere inizializzato. TDD di solito lo evita, perché vuoi inizializzare l'oggetto nei casi di test con meno sforzo possibile. Ciò si tradurrà in un accoppiamento molto lento.

Quando si eseguono i test di retrofit, il lavoro necessario deve essere inizializzato con l'oggetto in prova. Anche le asserzioni possono essere un sacco di lavoro a causa di dipendenze intricate. Per questo è necessario modificare il codice di produzione e interrompere le dipendenze. Utilizzando correttamente l'iniezione di dipendenza questo non dovrebbe essere un problema.

Answer 8

Preferisco l'approccio di KentBeck che è ben spiegato nel libro, Test Driven Development by Example - Kent Beck.

dalla tua domanda posso dedurre che non sei sicuro del funzionamento del telaio di prova - la scelta del corretto funzionamento del telaio di prova è molto importante per TDD o per i test di unità di scrittura (in generale).

Unico problema pratico con TDD è "Refactoring" (anche noi abbiamo bisogno di rifattorizzare il codice di test) richiede molto tempo.

Answer 9

Scegliere una piccola applicazione non critica e implementarla utilizzando TDD. All'inizio il nuovo modo di pensare si sentirà strano, ma forse dopo una settimana o due di pratica si riempirà di naturalezza.

Here is a tutorial application (nel ramo "tutorial") che mostra quali tipi di test scrivere. In questo tutorial si scrive codice per passare i casi di test predefiniti, in modo da entrare nel ritmo, e successivamente si scrivono i propri test. Il file README contiene istruzioni. È scritto in Java, ma puoi facilmente adattarlo a C#.

Answer 10

Ho lavorato per aziende che fanno test su unità/integrazione troppo avanti e quelli che fanno troppo poco, quindi mi piace pensare di avere un buon equilibrio tra i due.

Consiglierei TDD - Test Driven Development. Questo ti assicura una buona copertura ma continua anche a focalizzare la tua attenzione sul posto giusto e sui problemi.

Quindi la prima cosa che fai per ogni nuovo sviluppo è scrivere un test unitario, anche se non hai una singola classe da testare.

Pensa a cosa stai testando. Ora esegui il test. Perché non dovrebbe compilare? Perché hai bisogno di classA. Crea la classe ed esegui il test. Perché non lo compila? Perché non ha metodoA. Scrivi il metodo uno ed esegui di nuovo il test dell'unità. Perché il test fallisce? Perché methodA non è implementato. Implementare il metodoA ed eseguire il test. Perché fallisce? Perché methodA non restituisce il valore atteso corretto ... ecc.

Continui come questa unità di test durante lo sviluppo e alla fine il test passerà e il pezzo di funzionalità sarà completo.

Answer 11

Vorrei assumere TDD, sviluppo test-first, prima delle mock e iniezione dipendenza. Per essere sicuro, i mock possono aiutarti a isolare meglio le tue unità - e quindi a fare meglio i test unità - ma a mio avviso, il mocking e il DI sono concetti più avanzati che possono interferire con la chiarezza della semplice scrittura dei test.

Mock e DI hanno il loro posto; sono buoni strumenti da avere nella tua cassetta degli attrezzi.Ma prendono un po 'di sofisticazione, una comprensione più avanzata, rispetto al tipico neofita testante. Scrivere i test prima, tuttavia, è esattamente così semplice come sembra. Quindi è più facile da assumere, ed è potente da solo (senza mock e DI). Otterrai vincite precedenti e più facili scrivendo prima test privi di mock, piuttosto che cercando di iniziare con i mock, e TDD, e DI tutti in una volta.

Inizia con test-first; quando sei molto a suo agio con esso, e quando il tuo codice ti sta dicendo che hai bisogno di mock, poi prendere in giro.

Answer 12

Penso che il libro di Dave Astels sia ancora una delle migliori introduzioni. È per Java, ma dovresti essere in grado di tradurre.

Answer 13

Estendere la risposta di Steve Freeman: il libro di Dave Astel si chiama "Test-driven Development - A practical guide". Se il tipo di applicazione che stai scrivendo è un'applicazione GUI, questo dovrebbe essere utile. Ho letto il libro di Kent Becks ma non sono riuscito a capire come avviare un progetto con TDD. Il test del libro di Astel-guida un'applicazione GUI completa e non banale dall'inizio alla fine usando storie. Mi ha aiutato molto ad iniziare in modo acuto con TDD, mi ha mostrato dove e come iniziare.

Answer 14

Test Driven Development può essere fonte di confusione per i principianti, un sacco di libri che ho letto quando stavo imparando TDD avrebbe insegnato come scrivere unit test per una classe Calcolatrice, ma sembra che ci sia molto meno aiuto per la creazione di applicazioni del mondo reale , che sono più incentrati sui dati se oserei dire. Per me l'innovazione è stata quando ho capito cos'è lo sviluppo comportamentale o BDD e come iniziare a fare test da fuori. Ora posso semplicemente consigliarti di concentrarti sul comportamento dell'applicazione e scrivere test unitari per verificarlo. C'è un sacco di dibattito tra TDD e BDD, ma penso che test automatici ben scritti a tutti i livelli aggiungano valore e per scriverli dobbiamo concentrarci sul comportamento.

Hadi Hariri ha un eccellente post qui http://hadihariri.com/2012/04/11/what-bdd-has-taught-me/

Ho anche scritto alcuni articoli sul tema che mi sento aiuterà a comprendere tutti i concetti legati alla TDD qui

http://codecooked.com/introduction-to-unit-testing-and-test-driven-development/

http://codecooked.com/different-types-of-tests-and-which-ones-to-use/