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
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
C-/C++-Quelltext |
|
1 2 3 4 |
int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main |
Wenn die einzelnen Komponenten so stark untereinander gekoppelt sind, dass sie nicht einzeln getestet werden können, ist das ein Indiz für ein schlechtes Design.
Ich höre nur immer wieder als Gegenargument, man würde zu viel Zeit für das Schreiben der Testfälle aufbringen, welche man eher mit dem schreiben effektiv nutzbaren Codes verwenden sollte. (Wenn man die Vorteile des automatisierten Tests kennt, dann weiß man, warum der reine Zeitaufwand für das Schreiben von Testfällen eher kein richtiges Argument ist.)
In jedem Fall sollten sich zu Grunde liegende Funktionen und Algorithmen relativ gut testen lassen. Dazu gehören Wegfindung, mathematische Operationen, sofern selbst implementiert, usw.
Graphik kann man testen, indem man nach dem Rendern einer Test-Szene den Framebuffer ausliest.
Zitat
All tests passed (4173 assertions in 13 test cases)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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 |
// statt REQUIRE(object.getWorldPosition == {1.2f, 3.4f}); auto pos = object.getWorldPosition(); REQUIRE(pos.x == 1.2f); REQUIRE(pos.y == 3.4f); |
Werbeanzeige