spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

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)?

Zitat von »Glocke«

Da das Droppen (mit gegebener Liste von Items) zwar immernoch randomisiert ist, habe ich nach dem Droppen für jeden Spieler die Anzahl der Items gezählt und schließlich ein Histogramm erzeugt, welches mir angibt wie viele Items wie oft gedroppt wurden. Damit kann ich dann teste, dass 4 Items bei 2 Spieler zu genau 2x2 Items, und 5 Items bei 3 Spielern zu 1x1 und 2x2 Items führt.
[/list]

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.

Variable Seeds sind durchaus sinnvoll, indem die Assertion entsprechend angepasst wird. Andernfalls hat man einen sehr eingeschränkten Test und einen getesteten Code, der vielleicht gerade mit diesen Werten tut, aber mit anderen nicht. Oftmals sind es aber spezielle Wertekombinationen, die nicht funktionieren, obwohl es im "Normalfall" alles tut.

Zitat von »BlueCobold«

Variable Seeds sind durchaus sinnvoll, indem die Assertion entsprechend angepasst wird. Andernfalls hat man einen sehr eingeschränkten Test und einen getesteten Code, der vielleicht gerade mit diesen Werten tut, aber mit anderen nicht. Oftmals sind es aber spezielle Wertekombinationen, die nicht funktionieren, obwohl es im "Normalfall" alles tut.

Na gut, man muss hier die Unterscheidung nach der Art des Tests vornehmen. In einem Systemtest und vmtl. auch im Integrationstest kann man durchaus mit variablen Zufallszahlen testen. Einfach weil diese Testformen üblicherweise protokolliert werden und man dort die verwendeten Zufallszahlen festhalten kann.

Ein Unittest, der ohne ein Protokoll immer wieder während der Entwicklung läuft, sollte aber kein zufälliges Verhalten zeigen. Ein Fehlschlag kann da kaum nachvollzogen werden und wird leicht mit den letzten Änderungen in Bezug gebracht, obwohl der Fehlschlag einen ganz anderen Grund hat.

Auch da möchte ich wieder widersprechen, denn nur wenn so ein Unit-Test fehlschlägt, findet man solch üble Bugs. Bei uns wurden auf diesem Weg schon Bugs gefunden, die sonst nur grüne Tests geliefert hätte. Lieber einen flackernden Test, der einen schwer zu findenden Bug ab und zu anzeigt, als falsche grüne Wiese. Nur wenn solche Builds rot laufen, schaut überhaupt jemand rein. Laufen sie immer grün, weil der Test eine optimale Situation hat, schaut niemand. Warum Ihr bei Unit-Tests keine Protokolle habt, das weiß ich allerdings nicht. Dass da nicht jeder zufällig generierte Test-Wert drin steht, das mag wohl sein, ist aber auch egal. Einfacher zu finden mag es wohl sein, wenn es geloggt wäre, aber besser so als gar nicht. Zudem sollte die Assertion genug Informationen im Fehlerfall liefern, damit das Problem zumindest halbwegs ersichtlich ist.

Zitat von »BlueCobold«

Warum Ihr bei Unit-Tests keine Protokolle habt, das weiß ich allerdings nicht.

Die Unit-Tests laufen so oft wie möglich. Mindestens beim Build, wenn möglich sogar beim Speichern einer Datei. Ein fehlgeschlagener Test ist da wie ein Compilerfehler. Ich habe zwar noch nie geschaut, glaube aber nicht das die Testergebnisse irgendwo permanent gespeichert werden, da es auch einfach zu viele zum wiederfinden sind. Wenn man reproduzierbare Tests hat, zählt ja auch nur das letzte Ergebnis das man in der IDE stehen hat

Zitat von »BlueCobold«

Bei uns wurden auf diesem Weg schon Bugs gefunden, die sonst nur grüne Tests geliefert hätte. Lieber einen flackernden Test, der einen schwer zu findenden Bug ab und zu anzeigt, als falsche grüne Wiese. Nur wenn solche Builds rot laufen, schaut überhaupt jemand rein. Laufen sie immer grün, weil der Test eine optimale Situation hat, schaut niemand.

Das Argument kann ich durchaus verstehen und habe da sogar auch dran gedacht. Das Problem ist da vermutlich einfach das der Entwickler einen Fehler bekommen kann, der in einem Codeteil steckt mit dem er vielleicht gar nichts zu tun hat und vor allem den Test auch nicht kennt. Sowas wird dann schnell mal ignoriert und kann dann auf Dauer dazu führen das auch andere Tests nicht ernst genommen werden. Es betrifft ja nicht nur Zufallszahlen sondern auch Timingverhalten und anderen nicht-determinismus im Bezug auf die Tests. Da gibt es auch einen ganz guten Artikel von Martin Fowler http://martinfowler.com/articles/nonDeterminism.html

Wenn der Test von zufallsvariablen abhaengt und recht flott laeuft, kann es sich durchaus lohnen den Test mehrfach mit mehreren seeds laufen zu lassen. Ob man diesen nun zufaellig oder fix waehlt ist dann denke ich eine Frage der Philosophie wie man seine Unit Tests verwendet.

Zitat von »Tobiking«

Sowas wird dann schnell mal ignoriert und kann dann auf Dauer dazu führen das auch andere Tests nicht ernst genommen werden.

Da sollte wohl jemand überlegen grüne Tests in die Abnahmekriterien zu übernehmen Rote Tests zu ignorieren finde ich erschreckend.
Spannend finde ich, dass Tests bei Euch nicht nur im Build-Prozess laufen, sondern auch beim Entwickler wenn er Dateien speichert? Bei uns läuft der Build via Jenkins nach jedem Push inklusive aller Tests (Die Ergebnisse der letzten 5-20 [je nach Projekt] werden behalten, inklusive aller Logs, Artefakte, Test-Protokollen, etc). Die bei jedem Speichern laufen zu lassen ginge bei uns gar nicht, die sind viel zu umfangreich dafür. Erzähl mal mehr, das finde ich ein ungewohntes Konzept.

Zitat von »BlueCobold«

Zitat von »Tobiking«

Sowas wird dann schnell mal ignoriert und kann dann auf Dauer dazu führen das auch andere Tests nicht ernst genommen werden.

Da sollte wohl jemand überlegen grüne Tests in die Abnahmekriterien zu übernehmen Rote Tests zu ignorieren finde ich erschreckend.
Spannend finde ich, dass Tests bei Euch nicht nur im Build-Prozess laufen, sondern auch beim Entwickler wenn er Dateien speichert? Bei uns läuft der Build via Jenkins nach jedem Push inklusive aller Tests (Die Ergebnisse der letzten 5-20 [je nach Projekt] werden behalten, inklusive aller Logs, Artefakte, Test-Protokollen, etc). Die bei jedem Speichern laufen zu lassen ginge bei uns gar nicht, die sind viel zu umfangreich dafür. Erzähl mal mehr, das finde ich ein ungewohntes Konzept.

Laeuft bei uns eigentlich ganz aehnlich. Unit tests werden lokal waerend der Entwicklung genutzt.

Jedoch muss dazu gesagt werden, dass Chrome OS in gut 260 Teilprojekte unterteilt ist die fast alle relativ ueberschaubar sind. Schwierig wird es dann Fehler in der Zusammenarbeit zwischen den Teilprojekten zu finden wofuer es weitere level an tests gibt die von den Build Servern ausgefuehrt werden.

Das gruselige ist jedoch, dass der Linux Kernel fast gar keine automatisierten tests hat.

Na ja, lokal Tests während der Entwicklung zu nutzen ist ja normal. Aber bei jedem Speichern einer Datei klingt sehr Ressourcen-zehrend.

Zitat von »BlueCobold«

Na ja, lokal Tests während der Entwicklung zu nutzen ist ja normal. Aber bei jedem Speichern einer Datei klingt sehr Ressourcen-zehrend.

Das ist auch eher die Ausnahme als die Regel. Da hängt mit drin das man die relevanten Unit-Tests gut filtern können muss, und diese dann im Bereich unter 1s ausgeführt werden können. Wir haben es auch nur mal mit NCrunch (http://www.ncrunch.net/) evaluiert und ich habs privat beim Webdev (NodeJS und Gulp) verwendet. Es ist halt bei TDD ziemlich großartig, weil du immer direktes Feedback bekommst wie der Stand des Tests ist. Und man kann sich auf die Tests beschränken die man gerade schreibt.

Ansonsten ist die übliche Staffelung bei uns: Unit-Tests lokal von Hand getriggert bei der Entwicklung, Integrationstest lokal optional vor dem Einchecken, Integrationstest Buildserver beim nightly build und Systemtest (nicht automatisiert) am Sprintende für neue und geänderte Features und zum Release komplett. Wir haben noch das Ziel die Integrationstest bei jedem Einchecken auf dem Buildserver laufen zu lassen, allerdings lässt das unser Setup noch nicht zu.