spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Tobiking«

Das klingt doch schon mal ganz ordentlich. Mich würde noch interessieren wie deine Erfahrung im Bezug des Nutzen der Unittests sind. Hast du Fehler entdeckt beim Test schreiben? Sind beim Weiterentwickeln alte Tests fehlgeschlagen (Stichwort Regression)?

Nach meinen bisherigen Erfahrungen bin ich regelrecht froh flächendeckend für mein Projekt Unittests eingeführt zu haben! Gerade wenn man alleine arbeitet neigt man dazu kleine Dummheiten einzubauen und den Code dann als "trivial" und "funktioniert eh" abzutun. Nicht wenige Male belehrte mich das Ergebnis der Tests eines besseren Teilweise waren aber auch verzwicktere Fehler drinne die ich - so denke ich - ohne Unittests vermutlich nur extrem schwer bis gar nicht gefunden hätte. Und es waren auch ein paar Sachen dabei die so vermutlich im fertigen Spiel nicht passieren, aber dennoch meiner Spezifikation, was der getestete Code leisten können soll, doch nicht erfüllte. Allein aus diesen Gründen habe ich automatisierte Tests sehr ins Herz geschlossen

Zum Thema fehlgeschlagene Tests durch Weiterentwicklung des bestehenden Codes .. unzählige male! Refactoring ist das, was ich bisher immer gefürchtet habe, weil man nie weiß wie viel und was man nun wirklich dadurch kaputt macht. Und auch hier: alleine neigt man dazu auch hier Änderungen mit "wie sollen die schon [...]" abzutun - und auch hier kamen die roten Lämpchen Mittlerweile ist Refactoring eine wunderschön handhabbare Sache geworden

Zitat von »Tobiking«

Nutzt du dann für den Test wechselnde Zufallszahlen? Das würde ja bedeuten das die Tests nicht mehr reproduzierbar sind und der Test mal erfolgreich sein kann und mal fehlschlagen könnte. Das ist eigentlich etwas was man verhindern möchte und deswegen im Test mit festen Seeds arbeitet.

Naja der Code verteilt die Items tatsächlich nicht völlig zufällig sondern stellt sicher, dass jeder Spieler eine bestimmte Anzahl an Items bekommt. Und genau diese Postcondition ist es die ich mit dem Test durch das Histogramm versuche zu erfassen.

Und ich bin froh, dass ich die Unittests direkt in meinen Buildprozess eingebaut habe (in meinem Fall in meine CMake-Konfiguration)... es ist einfach ein Traum Inzwischen sieht man Workflow zum Implementieren eines neuen Features wie folgt aus:

1. Design: Erstmal kläre ich ab welche Abhängigkeiten (in Form von Daten und Events) ich habe bzw. brauche, überlege mir dann die grobe Struktur und halte das erstmal in Stichpunkten fest. Nach einiger Zeit (in der ich an anderen Features gearbeitet habe), sehe ich über die Notizen drüber und überarbeite sie ggf.
   
2. Deklaration: Sobald ich das Feature umsetzen will baue ich mir zuerst den/die notwendigen Headerfile(s), deklariere notwendige Funktionen, Strukturen, Klassen inkl. Signaturen und schreibe kurze Kommentare zu pre- und post-conditions und anderen Infos.
   
3. Danach kommt schon die Implementierung .. dazu ist eigentlich nicht viel zu sagen: Prinzipiell implementiere ich erstmal alles was zum Feature gehört ohne zu kompilieren.
   
4. Schließlich schreibe ich (bevor die Implementierung überhaupt kompiliert wurde) meine Unittests auf Grundlage der vorher erstellten Kommentare (Conditions etc.) und klopfe erstmal so viele Fälle ab wie mir in den Sinn kommen. Dabei schaue ich auch immer wieder in die Implementierung "ach ja, das und das müsste dann rauskommen" und füge weitere Test hinzu.
   
5. Kompilieren, Linken, Testen ... hoffentlich Meistens sind ein paar Tippfehler und eine Hand voll gescheiterter Tests zu korrigieren - seltener geht mal was wo anders kaputt.
   

Und danach geht's in den nächsten Zyklus zum nächsten Feature. Im Moment habe ich die Implementierungen nur automatisiert getestet - jeweils in Isolation; ohne irgendwelche Grafiken wirklich zu zeichnen etc. Vor ein paar Tagen habe ich mal alles was zur Physik gehört einem Integrationstest durchzogen, um die Event-mäßige Zusammenarbeit zu testen .. das hatte glaube ich 2 Tage gedauert; Ergebnis war, dass ich ein Subsystem komplett neu implementiert habe (irgendwie war's Gülle xD) und zu den anderen Systemen die Tests neu geschrieben bzw. erweitert habe. Man lernt immer wieder dazu

Zitat von »DeKugelschieber«

TDD wäre Schritt 4 als erstes und dann der Rest.

Sehe ich auch so Nur bin ich im Moment "noch nicht soweit", dass ich mich dazu "durchringen" kann Aber ich habe mir vorgenommen es demnächst einfach mal so zu machen .. vllt. überzeuge ich mich ja selber