Test-getriebene Entwicklung bezeichnet den Vorgang Software mit automatisierten Softwaretests zu erstellen. Im Bereich von C# mit .NET wird hierfür meistens NUnit verwendet und dies ggf. mit TestDriven.Net. Test-getriebene Entwicklung unterteilt sich in sogenannte „Box“-Methoden und zwar genau in drei. Hier wäre zunächst der Black-Box-Test, der Grey-Box-Test und zu guter letzt der White-Box-Test. Um Test-getrieben entwickeln zu können, muss man sich dieser Methoden in klaren sein und diese Beherrschen. 

White-Box-Tests: 
Unter den White-Box-Tests fallen sämtliche Tests, die nach der Entwicklung der eigentlichen Funktionen geschaffen werden. Hierbei ist es natürlich sehr komfortabel da man stehts auf einen Kompilierfähigen-Status bleibt und die Tests in schnellen abfolgen erstellen und ausführen kann. Allerdings läuft man hier auch Gefahr, den Quellcode nicht sauber zu testen da oftmals Fehlerfälle und auch nur selten alle positiven Fälle abgetestet werden. Aus persönlichen Gründen würde ich aufgrund der Nachteile von White-Box-Tests abraten da diese viel Disziplin erfordern und eine saubere Vorgehensweise, welche in der Praxis durch Zeitdruck immer wieder erschwert wird.

Grey-Box-Tests: 
Grey-Box-Tests definieren Tests welche vor der Funktionalität geschaffen werden. Bei Grey-Box-Tests definiert man zunächst die zu testenden Methoden ohne Funktionalen Inhalt (hier sollte eine „NotImplementedException“ zunächst geschmissen werden). Anschließend definiert man sämtliche Tests sowohl die guten als auch die schlechten States welche erfolgen können. Es sollten auch Exceptions sowie ungültige Results geprüft werden. Und erst zum Schluss werden die Methoden implementiert. Das heißt auch das vor dem Implementieren die Tests natürlich Fehlschlagen sollten – zumindest in den meisten Fällen.

Black-Box-Tests: 
Zu den Black-Box-Tests gehören sämtliche Tests die ohne Kenntnis des Quellcodes geschaffen werden. Hierzu zählen auch etwaige BETA und ALPHA Tests der Software. Auch Benutzeroberflächentests sind hier anzuordnen, da diese in der Regel nicht automatisiert getestet werden können, sondern Sicht-Tests erfordern. Black-Box-Tests sollten eigtl. immer Verwendet werden und immer mit Grey- oder White-Box-Tests erweitert werden um so auch wirklich eine Sinnige Testabdeckung zu schaffen.

Meine persönliche empfehlen – auch aufgrund der praktischen Erfahrungen – würde sich überwiegend zu den Grey-Box-Tests hinziehen. Allerdings ist bei sämtlichen Tests hinzuzufügen, dass es nicht Sinnvoll ist Property Zuweisungen welche diese direkt Zuweisen zu testen oder ob der Konstruktor Funktioniert. 100%ige Testabdeckung hört sich zwar nett an, ist aber nahe zu immer none-sense.

Der größte Vorteil jedoch von all diesen Methoden ist, das bei späteren Änderungen diese durch die Tests direkt auffallen, sollten diese daraufhin Probleme auslösen. Von daher sollte eigentlich, auch wenn es oft einiges an Zeit kostet, im Sinne der Entwickler und im Sinne des Kunden Tests möglichst ausführlich durchgeführt werden.

Da es sich jedoch bei Test getriebener Entwicklung um ein relativ Komplexes Thema handelt, welches von Sprache zu Sprache, von IDE zu IDE und von Framework zu Framework komplett Unterschiedlich ausfallen kann, wie dies ausgeführt wird, hier eine Reihe an Referenzen:

Test-getriebene Entwicklung Wikipedia
White-Box-Tests Wikipedia
Grey-Box-Tests Wikipedia
Black-Box-Tests Wikipedia