Is it practical to use a testing framework like JUnit in a game development situation? What sort of design considerations can you follow in order to make your game more testable? What parts of a game can/should be tested and what parts should/must be left to human testing?
For example, if the game loop is encapsulated in one function, it seems like it would be terribly hard to test. I like to refactor out an "update" function that takes a time delta and moves forward the game logic; this allows some interesting tricks like the ability to slow the game down by feeding it fake, slower time deltas.
Answer
One of the tenets of TDD is that you let TDD in some cases influence your design. You write a test for system, then write the code to make that test pass, keep dependencies as shallow as possible.
For me, there are only two things I don't test as part of unit testing:
First, I don't test visual elements and how things look. I test that and object will be in the right place after it updates, that a camera will cull an object outside it's bounds, that transforms (at least those that are done outside of shaders) are performed properly before being handed over to the graphics engine, but once it hits the graphics system I draw the line. I don't like trying to mock out things like DirectX.
Second, I don't really test the main game loop function. I test that every system will work when passed a reasonable delta, and that systems work together correctly when they need to. Then I just update each system with the correct delta in the game loop. I could actually have a test to show that each system got called with the correct delta, but in many cases I find that overkill (unless you're doing complex logic to get your delta, then it's no overkill).
No comments:
Post a Comment