spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Viele haben direkt Faulheit als einzig gültige Entschuldigung angeführt. Darum wollen wir mal hier den Mantel des Schweigens über die vielen falschen Ausreden ausbreiten.
Man kann jetzt darüber diskutieren, ob denn ein fertig gerenderter Screen überhaupt ein Unit Test wäre. Ich sage mal eher nein. Das wäre wohl eher ein Integrationstest.
Unit Tests beziehen sich (wie der Name sagt) auf "Unit of work". Das Rendern eines Screens ist mit Sicherheit keine solche "Unit of work", sondern besteht aus vielen, vielen einzelnen
solcher Units. Mit Unit Tests sollte man diese einzelnen Units testen. Denn wenn alle einzelnen Units funktionieren, dann funktioniert auch das Ganze. So der Grundgedanke beim Unit Testing.
Ich persönlich verwende viele Unit Tests. Dazu habe ich ein separates Projekt. Hier binde ich meine Engine ein und habe dort dann einen Haufen Unit Tests.
Gerade eine Engine besteht aus so viel mehr als nur das Rendern.
Einen Schuß oder was auch immer kann man gut als Unit Test verpacken. Zumindest kann man testen, ob der nach einer gewissen Zeit auch an einer gewissen Stelle ankommt.
Dazu brauch man den ja nicht zu rendern. Ob der dann auch gut aussieht ist etwas anderes.
Trotz allem Unit Testing gehört dann natürlich das manuelle Testen dazu. Aber das bezeichnet man auch eher als Integrationstest. Also läuft alles zusammen, sieht es gut aus, halt das ganze Bild zusammen.

Falsche Ausreden? Was soll der Scheiß? Mit den Integrationstest stimme ich dir allerdings zu, ist wirklich der passendere Begriff dafür.

Bitte ruhig bleiben!

Ich teste auch nur sehr wenig.
Bei meinem bisher komplexesten Spiel (Blocks 5) kam mit der Zeit immer mehr neue Spielelemente hinzu. Um sicherzustellen, dass alles noch wie gewünscht funktioniert, habe ich daher spezielle Test-Levels konstruiert, in denen die Elemente so interagieren müssen, dass am Ende etwas Bestimmtes passiert.

@buggypixels:
Es hat übrigens niemand von GUI-Unit-Tests geredet, sondern nur von Tests und Test-Automatisierung für GUI- und Grafik-Elemente und über das Testen des Zusammenspiels dieser Elemente.
Wie diese Tests benannt werden, darüber wurde gar nicht gesprochen. Unit-Tests hat sie ebenfalls niemand genannt. Es geht in diesem Topic ja auch gar nicht rein um Unit-Tests, sondern um Testing generell. Test-Automatisierung lässt sich weiterhin sowohl auf Unit-, als auch auf Regressions- und Integrations-Tests anwenden (Ja, auch Integrationstests kann man eventuell automatisieren. Manuelle Tests haben erstmal nichts damit zu tun, ob sie Unit-, Modul-, Regressions- oder Integrationstests sind). Das machen wir hier z.B. für jede einzelne User-Story. Die Frage von mir war lediglich, ob und wie größere Firmen für ihre Spiele und grafischen Elemente auch automatisierte Tests durchführen. Für GUI-Elemente machen wir das in meiner Firma jedenfalls. Nur ist ein DX/OGL-Context eben etwas ganz anderes als Elemente, die sich durch Handles, Reflection oder anderweitige Properties viel konkreter testen lassen als z.B. die Sterbe-Animation einer von einer Bombe getroffene Spielfigur und ob diese korrekt abläuft.

Zitat von »buggypixels«

Darum wollen wir mal hier den Mantel des Schweigens über die vielen falschen Ausreden ausbreiten.

Ich frag mich wirklich, wie du darauf kommst, das es eine falsche Ausrede ist?

Thoran