Utilizza Java e Python, ma un buon libro per imparare TDD è Sviluppo basato su test: per esempio .
Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism. When programming teams buy into TDD, they immediately see positive results. They eliminate the fear involved in their jobs, and are better equipped to tackle the difficult challenges that face them. TDD eliminates tentative traits, it teaches programmers to communicate, and it encourages team members to seek out criticism However, even the author admits that grumpiness must be worked out individually! In short, the premise behind TDD is that code should be continually tested and refactored. Kent Beck teaches programmers by example, so they can painlessly and dramatically increase the quality of their work...
Dai un'occhiata a The Art Of Unit Test . Ha molti esempi in .NET, ma usa Rhino Mocks piuttosto che Moq, che preferisco.
Copre TDD e Test unitari in generale molto bene.
Microsoft ha anche un libro: Test Driven Development in .NET (Microsoft Professional) , ma ho ancora per leggerlo.
Tutte le risposte precedenti sono ottimi punti di partenza, ma per essere onesti dovresti iniziare a provare a fare TDD. Per iniziare, accetta che qualsiasi test sia migliore di nessun test e lentamente dovresti iniziare a vedere i pattern nel tuo sviluppo. Cose che funzionano davvero bene, cose che sono più difficili da testare e resistenti ai cambiamenti. Quando ci si imbatte in un secondo momento, fare un passo indietro e vedere cosa è diverso / impedisce il cambiamento. Lentamente dovresti sentire le cose cambiare. Per me, il "punto di gobba" si stava rendendo conto che quando facevo TDD correttamente potevo andare a pranzo o anche andare a casa per il fine settimana e quando sono tornato, so esattamente dove mi trovavo. La metrica misurabile era che mi sentivo molto più rilassato. Per rispondere ad alcuni dei critici di TDD, ci vuole una maggiore quantità di tempo in anticipo, ma se prevedi che il tuo sistema duri, dovresti vedere il rimborso a lungo termine.
Dato che stai chiedendo di c #, Test di unità pragmatica in C # con NUnit Potrebbe essere una buona scelta. Non ho letto gli altri, quindi non posso confrontare.
Una cosa che non mi piace è che utilizza NUnit Mocks. Preferisco di più Moq personalmente. È un pasticcio, non si tratta del linguaggio o del framework, ma della pratica e del processo.
Trova un dojo di codifica che utilizza il TDD come parte dell'esercizio. In alternativa, avvialo uno :) oppure puoi iniziare a provare i kata con TDD.
Altrimenti, trova qualcuno che ha usato TDD molto e chiedigli qual è il suo flusso di lavoro. Ho scoperto che avere qualcuno che parla e discutere idee con te è molto importante quando stai provando un nuovo processo.