Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Du brauchst nicht jeden moeglichen edge case zu testen meiner Meinung nach.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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 meiner Erfahrung nach sind aber genau Edge Cases die Sachen, die einem am meisten um die Ohren fliegen.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »BlueCobold« (08.12.2014, 20:17)
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.
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.
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...)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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.
C-/C++-Quelltext |
|
1 |
bool ObjectPhysics::doesCollide(GameObject const & other) { // ... |
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...
C-/C++-Quelltext |
|
1 2 |
// würde einen non-owning pointer oder ggf. nullptr liefern - je nach dem ob ein Ziel gefunden wurde GameObject* ObjectAi::searchNextEnemy() { // ... |
und sich dann einen Ast freuen, weil er weiß, dass seine Matrizenaddition nach 6 Monaten immer noch assoziativ ist...
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige