Unit tests and game engines
Author
Hi, I'm currently wondering if It would worth it to add a set of unit tests to my game engine...
I do think unit test are a good thing, but I do not know if they are really usefull for games, as it's rather hard for an automated test to see if a mesh was rendered right or not...
Anyway, I can at least test my math routines...
The real question is : What's your point of view on unit tests in game engine developpment, how to implements them, is there a test framework more adapted to games than the others.
Thank you.
Quote:Original post by Mawww
I do think unit test are a good thing, but I do not know if they are really usefull for games, as it's rather hard for an automated test to see if a mesh was rendered right or not...
Anyway, I can at least test my math routines...
So write unit tests for your math routines (and everything else that can be tested in this way)
You're right, a lot of things can't (easily) be unit tested, and trying to do so would be far more trouble than it's worth (I suppose you could write to a texture, and then perform some image analysis on it to detect whether the mesh was rendered correctly, but... probably easier to just look at the damn mesh and say "That looks ok" [lol])
But generally, I like unit-tests for all the stuff that can be easily tested. (Your math library is a good example)
It's usually hard to determine if you're using an API correctly. The best thing to do is to write a few prototypes, and determine how the API should be used. Then, unit testing a model would consist in checking that it calls the correct API functions in the right order with the right arguments.
In general, when testing code based on side-effects, the idea is to parametrize it with the side-effect generation code, and provide your own code as a mock during the test, to see if the side-effect sequence is correct.
As for code based on state or on returned values, they are much easier to handle, as you might already know.
In general, when testing code based on side-effects, the idea is to parametrize it with the side-effect generation code, and provide your own code as a mock during the test, to see if the side-effect sequence is correct.
As for code based on state or on returned values, they are much easier to handle, as you might already know.
I'm using unit tests for quite a lot computative things (indeed math stuff) and also things like font rendering and image loading. I have already squashed so much bugs this way before they could rear their ugly heads in-game....
I'm still in doubt if I should include some tests, like rendering a scene, writing they framebuffer to a file and then compare it to the previous runs. It's a nice way to check if you broke something unintentionally, but you will need to update the reference image everytime you change your rendering code. So that might be more trouble than it's worth.
I'm still in doubt if I should include some tests, like rendering a scene, writing they framebuffer to a file and then compare it to the previous runs. It's a nice way to check if you broke something unintentionally, but you will need to update the reference image everytime you change your rendering code. So that might be more trouble than it's worth.
In a previous project we ran into problems testing a WPF GUI with our test tooling. Because the project would only last another three months we decided not to test the GUI. Instead we changed the software design so that the GUI part did not contain much code. For example, button event handlers only had one line of code in them. So we could test all the functionality without testing the GUI.
However, testing graphics can be done. Perhaps not the visual part, but the logic part can be tested. For example, you can override your texture bind routine and you can test if the texture is bound before a mesh is drawn. You can override your translation/rotation routines and see if the matrix is translated/rotated properly before drawing an object.
Surely, the actual visual stuff you still need to verify yourself. But I don't think you want to put that in a unit test anyway. It would be too much work to keep the tests up-to-date with the code, as you usually spend a lot of time tweaking the actual visuals.
However, testing graphics can be done. Perhaps not the visual part, but the logic part can be tested. For example, you can override your texture bind routine and you can test if the texture is bound before a mesh is drawn. You can override your translation/rotation routines and see if the matrix is translated/rotated properly before drawing an object.
Surely, the actual visual stuff you still need to verify yourself. But I don't think you want to put that in a unit test anyway. It would be too much work to keep the tests up-to-date with the code, as you usually spend a lot of time tweaking the actual visuals.
Some time ago (about 2 years) Noel Llopis wrote about TDD in game development in his blog and it has some great opinions about what to test and what not to.
You can find all the articles in:
http://www.gamesfromwithin.com/articles/cat_testdriven_development.html
Hope this helps!
You can find all the articles in:
http://www.gamesfromwithin.com/articles/cat_testdriven_development.html
Hope this helps!
Unit test everything that can be unit tested. Don't unit test things like the output from your renderer - the only way to do that is visual inspection. We used to store bitmapped screen grabs of what the output looked like, and the unit test would compare it's output to the bitmap; but the slightest change to one parameter or shader or function anywhere and it would fail the test. It's really not worth it.
Test things that are either correct or not, basically. You will catch lots of bugs doing it, and the earlier the better.
Test things that are either correct or not, basically. You will catch lots of bugs doing it, and the earlier the better.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
