spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Unit-Tests, Test-Automatisierung, manuelle Tests. Privat nur letzteres, obwohl die ersten beiden vermutlich gerade bei wachsendem Projekt für Bestandsfunktionalität echt sinnvoll wären. Eigene Faulheit...

Bei mir wie bei BlueCobold. Testklassen sind super, aber bei privatem Zeug bin ich eigentlich fast immer zu Faul dafür.

Solange du nicht für die Rüstung programmierst, sind Fehler meist reversibel oder zumindest leidlich gut zu regulieren. Gerade für den Hobbybereich lohnt sich der Aufwand von ausführlichen Tests wohl kaum.

ja, Unittests stellen wohl eine der besten Testmöglichkeiten dar (und auch ich teste privat dennoch meist nicht auf diese Art)

anbei werfe ich auch mal Testgetriebene Entwicklung in den Raum

Ich machs genauso wie BlueCobold und Schorsch. Unit Tests wären schon super, aber... auch die eigene Faulheit.

Bei mir sind Test auf der ToDO-Liste, war aber bisher auch zu faul. Eigentlich geht das gar nicht, den letzten Endes spart einem das Zeit bei der Fehlersuche
Vorerst müssen erstmal noch ein paar Features fertig gemacht werden.

Thoran

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.
Aber ja, ingesamt spart das meist Zeit bei der Betrachtung des Gesamt-Prozesses. Gerade Hobby-Entwickler sehen aber vermutlich eher neue Features als Priorität und Bugfixing wird einfach zwischendrin gemacht. Die gefühlte Entwicklungs-Geschwindigkeit ist ohne Tests höher, was meist aber ein Trugschluss ist.

Ich denke als Spiele-Entwickler gibt es vor allem auch das Problem, dass GUI-Tests nicht trivial sind. Meist sind alle Elemente ja doch OpenGL oder DirectX, was bedeutet, dass die einzelnen Komponten der GUI oder die dargestellten Game-Elemente nicht per Handle extern durch Tests erreichbar und somit Tests der visuellen Komponenten nicht schwer durchführbar sind. Würde mich mal interessieren, wie das bei professionellen Firmen automatisiert wird. Wie testen die den visuellen Output von Engines, Modelle, Beleuchtungen, usw.? Ist das überhaupt automatisierbar und wie weit? Wäre ein netter Vortrag für die Devmania... (Vorträge von externen Professionellen - außer mal TGGC, der ist ja eh intern - wären eine coole Sache und würden mich vielleicht sogar mal dahin bewegen)

Hab das Buch Game Coding Complete hier rumliegen. Kann mich nicht dran erinnern, dass er von automatisierten Tests in dem Buch spricht. Mag aber auch sein, dass ich das einfach verdrängt habe. Sicherlich wird auch in der Spielebranche so getestet. Da er aber zwischendurch immer mal wieder den Prozess der Fehlersuche und auch Fehlerentdeckung bei bestimmten Projekten beschreibt, wirkt es für mich so, dass zumindest nicht alles automatisiert getestet wird. Natürlich sind das jetzt nur Vermutungen. Andererseits gibts dann ja immer noch die QA die sich um sowas kümmern könnte.

Zitat von »BlueCobold«

Ich denke als Spiele-Entwickler gibt es vor allem auch das Problem, dass GUI-Tests nicht trivial sind. Meist sind alle Elemente ja doch OpenGL oder DirectX, was bedeutet, dass die einzelnen Komponten der GUI oder die dargestellten Game-Elemente nicht per Handle extern durch Tests erreichbar und somit Tests der visuellen Komponenten nicht schwer durchführbar sind. Würde mich mal interessieren, wie das bei professionellen Firmen automatisiert wird. Wie testen die den visuellen Output von Engines, Modelle, Beleuchtungen, usw.? Ist das überhaupt automatisierbar und wie weit?

Ich hab mir da die Tests von Irrlicht abgeguckt. Dort wird einfach etwas gerendert und dann ein Screenshot gespeichert. Beim nächsten rendern wird dann der erzeugte mit dem schon vorhandenen verglichen.
Ist zwar nicht vollständig automatisiert, weil man ja immer beim ersten rendern drüber gucken muss, ob das alles richtig ist, aber danach läuft das ja von alleine.