Problematisch wird es halt, wenn viele Objekte zusammenspielen. Wenn man vielleicht eine neue Art von Schuss einbauen will, die Gegner auf eine interessante Art tötet, kann es sehr mühsam sein, ein Testszenario aus Objekten zusammen zu bauen, und dann im Code abfragen, ob das eingetreten ist, was man erwartet hat ("Gegner fliegt im Hohen Bogen aus dem Level" lässt sich schwer in ne Abfrage packen...) von daher teste ich das dann halt interaktiv im Spiel. Oder so etwas wie ShadowMapping: Viel rumzutesten, aber man kann ansich nur am Screenshot entscheiden, ob es jetzt richtig ist oder nicht. Klar könnte man die Shadowmap rendern, einzelne Pixel auslesen und mit erwarteten Werten vergleichen, aber was ist das denn bitte für ein Aufwand? Und ich hatte es fast noch nie, dass irgendein Feature durch ein neues kaputt ging, und wenn hab ich es eigentlich immer gemerkt. Und wenn nicht, ist es vielleicht ein kniffeliges Zusammenspiel vieler Komponenten, für das ich eh keinen Test gehabt hätte.
Die Idee von Unit test klingt ja ganz cool, "Ich baue einzelne Test und kann die automatisiert durchlaufen lassen, so weiß ich imemr, das noch alles funktioniert", aber für Spiele halte ich es für nicht so gut geeignet. Für einzelne Teile (Physikengine oder so) bestimmt super, aber Spiellogik und Grafikeffekte eher nicht so.
Fast noch wichtiger als viel Testen finde ich es, die Software robust zu designen, so dass viele Fehler erst gar nicht auftreten können. Das Klassen Interfaces haben, die es schwer machen sie falsch zu benutzen, das man bei Fehlern Exceptions schmeißt (wer prüft schon alle Rückgabewerte?) und dass das ganze eine logische Struktur hat (netterweise wird dadurch der Code meistens sogar kürzer und besser verständlicher). Auch toll sind Versionsverwaltungssysteme wie git, wenn irgendetwas nicht mehr geht, sieht man so sehr schnell, an welchen Stellen man etwas geändert hat (wodurch man schneller zum Fehler kommt). Achja und Bugs immer mit hoher Priorität beheben (oder zumindest die Ursache finden, manche Fehler lassen sich ja nur durch größere Umbauten beheben). Wenn man ersteinmal verstanden hat, was das eigene Programm eigentlich macht, ist man schon einen großen Schritt weiter in Richtung Fehlerfreiheit.
Mein Testen beschränkt sich also meistens auf "sehr oft neu kompilieren und gucken ob das Programm das tut, was man erwartet".
Aber würde ich Unit-Tests mit C++ machen, würde ich wohl googletest benutzen, das sieht sehr einfach und brauchbar aus.