spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »TheBenji«

Du brauchst nicht jeden moeglichen edge case zu testen meiner Meinung nach.

Also meiner Erfahrung nach sind aber genau Edge Cases die Sachen, die einem am meisten um die Ohren fliegen.
Das man es auch übertreiben kann ist aber wohl wahr.

Zitat von »Sylence«

Also meiner Erfahrung nach sind aber genau Edge Cases die Sachen, die einem am meisten um die Ohren fliegen.

Genau so ist es. Die üblichsten Fälle hat ja man meist bei der Entwicklung schon mal ausprobiert. Aber die Edge Cases nicht. Und da knallt es meist gehörig (fehlende Nullpointer-Checks z.B.).

Also ich habe schon von einigen Leuten viel gutes über Unit-Tests gehört, und mich auch schon einige male damit beschäftigt, sie aber letztendlich dann doch nie angewandt. Meiner Meinung nach gibt es einfach in spielen extrem viele Dinge, die extrem schwer durch Unit-Tests abzudecken sind.

Ich meine, so simple Algorithmen oder Funktionen (Kreuzprodukt z.B.) sind meist so simpel, dass man wenig falsch machen kann. Meistens jedoch nimmt man wohl eh ne fertige Implementierung und die stimmt dann eh. Und für viele andere Dinge hat man dann sehr sehr schnell so komplizierte Testfälle, dass ich persönlich dafür keinen Test schreiben will. Man kann eben einfach nicht jede Funktion getrennt betrachten, ein paar Eingabewerte reinschmeißen und gucken ob das Ergebnis stimmt.
Nehmen wir die Kollisionsabfrage: Man hat ein Terrain als Heightmapt, generiert daraus Dreiecke, repräsentiert den Spieler durch eine Kugel oder Zylinder und will gucken, ob die Kollisionsabfrage passt. Viel Spaß beim Ausrechnen der Testdaten. Alternative: Man baut in sein Programm schnell ne Debuganzeige ein und testet es gerade durch.
Oder nehmen wir die KI: Computergegner sollen auf das reagieren, was der Spieler macht. Wird auch sicherlich spaßig, wenn man einen kompletten Spielablauf simulieren will. Natürlich kann man auch einfach gucken, bei welchen Werten ein interne KI-Zustand umgeschaltet wird und gezielt solche Werte oben reinschmeißen. Damit testet man dann aber nicht mehr die KI, sondern guckt, ob die if-Abfrage funktioniert. Und das tut sie halt immer...

Tests mögen gut sein, wenn man wenig Eingabewerte, wenig Ausgabewerte und eine komplexe Logik dazwischen hat. Und eine gute Möglichkeit, Testfälle zu generieren.

Anders sieht es halt aus, wenn man Python oder PHP programmiert. Wenn C++ kompiliert wird, wird ja schon eine Art statische Code-Analyse betrieben, ein syntaktisch korrektes Programm kann schonmal einen riesigen Haufen Blödsinn nicht mehr machen (Variablen benutzen die nicht existieren, z.B.). In Python kann es halt passieren, dass dein Programm jahrelang ohne Probleme läuft und dann einmal ein seletenes Code-Fragment ausgeführt wird, in dem ein Syntax-Fehler ist. Ist dann oft trivial zu beheben, aber man muss eben wirklich jeden Programmpfad irgendwie testen, um alle derartigen Fehler zu finden.
Wenn man sich in C++ dagegen etwas mühe gibt (RAII, const-correctness, keine manuelle Speicherverwaltung, Exceptions statt Rückgabewerte die jeder vergisst zu testen) kann man meiner Meinung nach schon sehr sehr robuste Programme schreiben, bei denen viele Dinge die man sonst mit Unit-Test überprüfen würde, gar nicht erst auftreten.
Ich würde daher lieber mehr Zeit in ein sauberes und robustes Design stecken, als unnötige Unit-Test zu schreiben, nur weil sie gerade in sind (ich will nicht sagen, dass alle Unit-Test unnötig sind, aber wenn man einfach welche schreibt, um Unit-Test zu haben weil Unit-Test ja toll sind, wird gerade jemand mit wenig Erfahrung vermutlich haufenweise überflüssige Tests schreiben, und sich dann einen Ast freuen, weil er weiß, dass seine Matrizenaddition nach 6 Monaten immer noch assoziativ ist...)

Falls du deine Matrizenaddition irgendwann mal mit AVX umsetzt wirst du dich wahrscheinlich freuen gleich ein paar vernünftige Tests parat zu haben ...

Wenn sich dein Code nie ändert wird, wird wahrscheinlich selten ein Test mal fehlschlagen. Ich geh mittlerweile aber eher davon aus, das jeder Code irgendwann mal gewartet wird.

Zitat von »Jonathan_Klein«

Ich meine, so simple Algorithmen oder Funktionen (Kreuzprodukt z.B.) sind meist so simpel, dass man wenig falsch machen kann. Meistens jedoch nimmt man wohl eh ne fertige Implementierung und die stimmt dann eh.

Wenn du der fertigen Implementierung traust, brauchst du diese natürlich nicht zu testen. Wenn aber später deine KI nicht das tut was sie soll, und es dann letztendlich am falschen Kreuzprodukt liegt, während du an der falschen Stelle suchst, wirst du dich ärgern. Und wie schon erwähnt wurde, wenn du die Implementierung tauscht (Neue Version, Optimierung oder Portierung auf anderes System) bist du froh, wenn du ein Indiz hast, dass diese sich grundsätzlich gleich verhält.

Zitat von »Jonathan_Klein«

Nehmen wir die Kollisionsabfrage: Man hat ein Terrain als Heightmapt, generiert daraus Dreiecke, repräsentiert den Spieler durch eine Kugel oder Zylinder und will gucken, ob die Kollisionsabfrage passt. Viel Spaß beim Ausrechnen der Testdaten. Alternative: Man baut in sein Programm schnell ne Debuganzeige ein und testet es gerade durch.

Ich sehe nicht wo das Problem hier sein soll. Die Kollisionsabfrage wird wohl eine Reihe von Objekte (als Menge von Dreiecken) auf Kollision prüfen. Also lade ich je eine Szene wo die Objekte kollidieren, sich berühren und getrennt voneinander sind. Dann frage ich das Ergebnis der Kollisionsprüfung ab und kontrolliere es mit dem was es sein soll. Ich habe hier natürlich die Abhängigkeit zum Level-Loader. Aber wenn ich für diesen separate Tests habe, erkenne ich das es sich um Folgefehler handelt.

Zitat von »Jonathan_Klein«

Oder nehmen wir die KI: Computergegner sollen auf das reagieren, was der Spieler macht. Wird auch sicherlich spaßig, wenn man einen kompletten Spielablauf simulieren will. Natürlich kann man auch einfach gucken, bei welchen Werten ein interne KI-Zustand umgeschaltet wird und gezielt solche Werte oben reinschmeißen. Damit testet man dann aber nicht mehr die KI, sondern guckt, ob die if-Abfrage funktioniert. Und das tut sie halt immer...

Einen Zustandsübergang würde ich nicht testen. Von einem KI Modul würde ich auch eher erwarten, dass es eine Situation (Umgebung + Positionen Spieler und eigene) übergeben bekommt und eine Aktion (z.B. Laufe + Router) zurückgibt. Das kann ich testen.

Zitat von »Jonathan_Klein«

Tests mögen gut sein, wenn man wenig Eingabewerte, wenig Ausgabewerte und eine komplexe Logik dazwischen hat. Und eine gute Möglichkeit, Testfälle zu generieren.

Ich glaube du erwartest zu viel bzw. das falsche von Unit Tests. Sie sollen die Qualität der Software erhöhen, indem sie den Entwickler unterstützen Fehler zu finden. Sie sollen nicht bescheinigen das eine Software fehlerfrei ist. Das ist praktisch unmöglich. Deswegen braucht man auch nicht so unglaublich viele Testfälle.

Zitat von »Jonathan_Klein«

Ich würde daher lieber mehr Zeit in ein sauberes und robustes Design stecken, als unnötige Unit-Test zu schreiben, nur weil sie gerade in sind (ich will nicht sagen, dass alle Unit-Test unnötig sind, aber wenn man einfach welche schreibt, um Unit-Test zu haben weil Unit-Test ja toll sind, wird gerade jemand mit wenig Erfahrung vermutlich haufenweise überflüssige Tests schreiben, und sich dann einen Ast freuen, weil er weiß, dass seine Matrizenaddition nach 6 Monaten immer noch assoziativ ist...)

Unit Tests bilden eine ziemlich gute Synergie zum guten Design, da es ein gutes Design braucht um Unit Tests schreiben zu können. Außerdem kann man beim Refactoring meist schnell sehen wenn was kaputt geht. Und als Dokumentation dienen sie auch. Immerhin zeigen sie Beispielhaft wie ein Modul verwendet wird.

Testautomatisierung wird bei uns schon aus einem massiv wichtigen Grund eingesetzt: Regression. Die meisten Fehler passieren nicht, wenn man zum ersten Mal etwas implementiert. Da testet man ja manuell eigentlich ausführlich. Sie entstehen, wenn man mal irgendwo irgendwas umbaut. Da hat man dann oft irgendwas nicht bedacht und schon ist der Bug entstanden. Ein automatischer Test findet solche Fehler sehr oft
Unit-Tests sind auch für Spiele problemlos möglich. Kompliziert wird es erst bei Modul-Tests und bei Tests, die Renderings überprüfen sollen. Bei Standbildern mag das noch gehen, aber sieht irgendein animierter Shader oder eine Animation richtig aus? Das sind dann typische Fälle für regelmäßige manuelle Tests nach festgeschriebenen Test-Abläufen.

Das gilt in der Tat nicht nur für die Spielentwicklung.

http://en.wikipedia.org/wiki/Test-driven_development
Mehr gibt's dazu nicht zu sagen.