spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

4173 Assertions? Hast Du da ewig große Loops oder woher kommt diese doch erstaunlich große Zahl an Assertions für so wenige Test-Cases?

C-/C++-Quelltext

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

TEST_CASE("Dungeon Terrain", "Dungeon") { auto terrain = createTerrain(); core::Dungeon dungeon{terrain, {64u, 64u}}; auto size = dungeon.getMapSize(); REQUIRE(size.x == 64u); REQUIRE(size.y == 64u); sf::Vector2u pos; for (pos.x = 0u; pos.x < 64u; pos.x++) { for (pos.y = 0u; pos.y < 64u; pos.y++) { auto tile = terrain[pos.x + 64u * pos.y]; REQUIRE(dungeon.getTerrain(pos) == tile); } } REQUIRE(dungeon.getTerrain({65u, 30u}) == core::Terrain::Void); }

Zitat von »BlueCobold«

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

Zitat von »BlueCobold«

Kleiner Tipp: Wenn Du schon Dimensionen prüfst, nimm verschieden große. Übliche Bugs bei sowas beruhen auf Copy-Paste, sodass x/y dieselben Werte erhalten, obwohl es eigentlich verschiedene sein sollten, weil vergessen wurde etwas nach dem Paste zu ändern. Wenn man mehrere Werte prüft, am besten immer unterschiedliche.

	C-/C++-Quelltext
1 2 3 4 5	void setSize(int x, int y) { this->someWeirdStuff()->getSize().x = x; this->someWeirdStuff()->getSize().y = x; // copy/paste bug }

Und glaub mir, Copy/Paste Bugs nehmen eine erstaunlich große Prozentzahl aller Bugs ein. So groß, dass teilweise hier schon gewisse Scrum-Master gedroht haben uns die Paste-Shortcuts zu sperren

Zitat von »4xfusion«

Testcases zum abdecken Deiner neuen Funktionen bzw. codes reichen völlig.
In erster Linie sollte es für Dich darum gehen, dass der Kram inklusive Tests erfolgreich durchläuft, dann bekommst Du wenigstens mit wenn grundlegende Dinge nicht funktionieren.
Rückgabewerte etc..

Als one man show sowieso nötig, weil es keinen code reviewer gibt ...
Also macht man sich mindestens die Mühe für funktionale Tests.

• valid movement
  
• tile collision
  
• levitate over terrain (manche Objekte können über gewisses Terrain drüberschweben)
  
• object collision
  
• gain focus by facing via straight direction
  
• gain focus by facing via diagonals (interessant zwecks maximaler Sichtweite)
  
• lose focus by movement
  
• ... usw.
  

• Meine Physik ist in drei Subsysteme zerlegt: Movement, Collision und Focus. Zum Focus System: Jedes Objekt kann in eine Blickrichtung (8 Richtungen) schauen, das nächste Objekt in Sichtweite wird dann fokussiert). Die Systeme interagieren untereinander über ein Eventsystem (einfache Structs die in Queues kopiert werden) und sind dadurch voneinander entkoppelt. Entsprechend kann ich jedes System einzeln testen: Das Collision-System bekommt z.B. MoveEvents (dass eine Kachel verlassen wurde), prüft dann auf Kollision und sendet ggf. ein CollisionEvent zurück. Mit ein paar gut gebauten Fixtures kann man den Setupcode schön verstecken und viele kleine Testfälle bauen - z.B. testen, dass eine Bewegung auf eine unbetretbare Kachel ein entsprechendes CollisionEvent auslöst etc.
  
• Im Grafik-Bereich habe ich zum einen ein Render- und zum anderen ein Animation-System. So kann ich Animationen testen ohne irgendwas zeichnen zu müssen. Test-Szenario: Objekt mit Animation-Komponente erzeugen und ein AnimationEvent in das System geben (dass z.B. die Attack-Animation abgespielt wird). Anschließend kann man die Daten der Animation-Komponente des Objekts abchecken: Ist die richtige Animation gesetzt? Befindet sich der Frame-counter am Anfang der Animation? Genauso ist es möglich das Animationssystem zu updaten (um die aktiven Animationen weiterlaufen zu lassen). Dann kann man prüfen ob die Frame-counter auf die richtigen Frames verweisen, ob die Animation vllt. sogar schon beendet wurde etc. pp.
  
• Im Render-System habe ich das erste mal nicht alles getestet. Allerdings konnte ich das Culling soweit vom Rest isolieren, dass ich in Unittests Beispielszenarien erzeuge und einmal culle, und dann den CullingBuffer (eine meiner Struktur die alle zu zeichnenden Kachelvertices und Sprites enthält) bgzl. seines Inhaltes prüfen kann. So lässt sich z.B. testen, dass nicht das gesamte Terrain gecullt wird etc.
  
• Deutlich mehr High-Level sind dann die Implementierungen meiner Spielerinventare und Quickslot-Leisten (in denen Items oder Zauber abgelegt werden können). Also habe ich entsprechende Klassen "Inventory" und "Quickslot" gebaut und (schon fast zu offensichtliche) Dinge getestet: Dass identische Items stacken, Items entfernt werden können wenn sie im Inventar vorhanden sind etc. pp.
  
• Besonders lustig war das Looting-System: Da habe ich mir (da ich ein Splitscreen-Coop anstrebe) das Droppen vom Looten getrent. Beim Droppen werden die Items halbwegs gleichmäßig verteilt und beim Looten dann die "vorgemerkten" Items schließlich eingesammelt. 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.