spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

So haben wir es auch gemacht, alles was eher optischer Natur war gerendert und Screenshots gespeichert, pro Testdurchlauf ein eigens verzeichniss, so dass man später Vergleiche anstellen konnte. Die Logik dahinter ist wiederum eine andere Sache, dafür gibt es die Trennung zwischen View, ViewModel und View, je nachdem wie fein man das haben möchte oder braucht.

Klappte auch immer hervorragend.

Das macht spezielle Partikel-Effekte, Flugbahnen und Animationen generell aber noch immer sehr kniffelig. GUI mag gehen, das kann ich mir auch gut vorstellen. Aber visuelle Spiel-Elemente mit dynamischem Verhalten (wird bei Event X auch Effekt Y oder Animation Z getriggert und korrekt dargestellt)?

Dass ist wirklich eine andere Sache, aber zumindest die wird EventX und EventY ausgeführt geschichte ist noch testbar solange du die Möglichkeit hast den Aufruf zu überwachen. Vermutlich testet man das aber eher indem man die Szene spielt, bzw den konstruierten Anfang abspielt und das Resultat betrachtet. Sowas wie ganze Sequencen basieren ja wiederum auf kleinere bauteile wie das EventSystem, Collisionssystem (Trigger), Dialogsystem, etc. Wenn hier schon die UnitTests versagen liegt es schonmal nicht an der Sequenz. Sollte die Sequenz unerwartets abliefern ist dies mMn wiederum ein zeichen für den UnitTest, der in diesem Fall eventuell die Situation welches das Problem verursacht nicht korrekt abgebildet hat (weil der Test falsch ist oder gar fehlt).

Auf eine gute QA kann man sicher auf keinen Fall verzichten.

Zitat von »BlueCobold«

Es spart nicht unbedingt Zeit bei der Fehlersuche, aber vielmehr bei der Fehler-Feststellung. Also bei der Detektierung, dass überhaupt ein Fehler vorliegt oder durch ein neues Feature ein altes gebrochen wurde.

Es spart auch Zeit bei der Fehlersuche, weil der Test je nach Design die Fehlerquelle eingrenzt.

Zitat von »DerMark«

Sollte die Sequenz unerwartets abliefern ist dies mMn wiederum ein zeichen für den UnitTest, der in diesem Fall eventuell die Situation welches das Problem verursacht nicht korrekt abgebildet hat (weil der Test falsch ist oder gar fehlt).

Indeed. Wenn die Komponenten funktionieren sollte im Normalfall auch das Zusammenspiel klappen. Wenn nicht, ist das auch nur über Modul- oder Integrationstests herausfindbar.

Unit-Tests sind ja nur ein Konzept. Visual Studio bietet dafür auch nur eine der möglichen Test-Umgebungen. Kann man sich aber ganz simpel auch selber machen, ohne großen Aufwand.
Mit C# und Attributes wäre das natürlich sogar noch einfacher generisch zu halten als mit C++, aber auch für C++ sind solche Tests absolut keine Hürde.

Wie wäre es mit http://www.nunit.org/

Schon lange in Nutzung und auch relativ gut ausgereift

Für C++ gibts auch entsprechende Lösungen, leider nicht so komfortabel.

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.

Dazu vielleicht ganz interessant: Gamasutra: Automated Testing: Building A Flexible Game Solver
Ich nutze Tests zu selten. Oft merke ich, dass mir viele Fehler nicht passiert wären, hätte ich einen kleinen Unittest dafür gebaut. Serialisierung, Entity-Komponenten-Zusammenspiel, LOD Verfahren, Algorithmen und Strukturen zur Partitionierung von Raum (Octree, Grids, Hashmaps und Co.) usw. sind da gute Kandidaten. Oder wenn man etwas optimieren will, kann man die bruteforce Variante immer gut nutzen um die Ergebnisse des optimierten Verfahrens zu überprüfen. Sowas wird zum Beispiel in Bullet Physics gemacht.