Test-driven development finde ich für Spiele sehr hinderlich, weil sich die grafischen Elemente meist nicht so einfach testen lassen.
Deswegen habe ich es nur in den Raum geworfen und nicht einfach jeden versklavt und zur Benutzung gezwungen.
![^^](wcf/images/smilies/squint.png.pagespeed.ce.vVqemmKAwr.png)
Aber auch bei normaler Anwendungssoftware hat man i. d. R. Probleme beim automatisierten Test der Oberfläche. Dafür gibt es zwar auch wieder Tools, allerdings stellen diese wieder eine andere Art des Testens dar.
Diesem Problem entgegnet man grundsätzlich damit, indem man die Aktionen, die durch Eingaben an der Benutzeroberfläche ausgelöst werden, von der Oberfläche separiert. Auch wenn man jetzt meinen könnte, dass dies doch Gang und Gebe sein und von jedem so eingesetzt werden sollte, könnte es dennnoch (gerade unerfahrene) Entwickler geben, die sich darüber noch keine großartigen Gedanken gemacht haben.
Einmal ein Beispiel, wo man in einem Spiel TDD gut einsetzen kann:
Ich musste für mein Spiel (schon eine Weile her) einen "VariablenManager" schreiben, der die Spielinternen Variablen (hat nichts mit den C#-Variablen zu tun) verwalten soll. Man muss ihm sagen können, dass er eine neue Variable aufnehmen soll (Eigenschaften: Name, Typ, Standardwert, konstant, automatisch zurücksetzend), man muss Werte abrufen können (teilweise auch ohne den eindeutigen/"vollqualifizierten" Namen zu kennen), man muss Werte setzen können, man muss Werte zurücksetzen können, man muss das automatische zurücksetzen auslösen können und noch ein paar andere kleinere Dinge.
Meine Herangehensweise hatte einige Gemeinsamkeiten mit Unit-Tests: ich hatte ein Konsolenprogramm, welches die neu implementierte Klasse mit einigen Testdaten aufgerufen hat und immer darauf hingewiesen hat, wenn das tatsächliche Verhalten nicht dem erwarteten entsprach. Beispielsweise wenn ein Wert nicht gesetzt werden kann oder wenn ein Wert für eine Konstante gesetzt wurde oder wenn ein Wert nicht zurückgesetzt wurde oder...
Oder allgemeiner formuliert: überall da, wo man eine Klasse vollkommen losgelöst von allen anderen bereits vorhandenen Klassen implementieren kann.
Allerdings sollte man, eben aufgrund des bereits beschriebenen Nachteils, TDD nicht so konsequent einsetzen, wie bei der normalen Anwendungsentwicklung.
Derzeit habe ich damit angefangen, dieses automatisierte Testen in form von Unit-Tests wieder einzubauen, da ich es nach der Fertigstellung verworfen hatte, da die Funktionalität doch fertig implementiert war. Leider nur hatte ich den Code danach auch ein wenig refactort, das hat auch fast immer funktioniert, nur leider hatte das auch schonmal die Funktionstüchtigkeit der Klasse zerstört und ich durfte erstmal debuggen (wobei ich da nicht davon ausgegangen bin, dass es an dieser Klasse liegt).