• Advertisement
Sign in to follow this  

Test driven development - can I do it with games?

This topic is 4575 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I'm listening to a slideshow on test driven development - and it sounds really interesting. But, is it possible to do this with game development? I mean, I have my camera class, how can I write tests for it? Would it be like... 1. Create a camera 2. Set desired properties (fov, clear color, etc) 3. Create a matrix that is what the projection matrix SHOULD be. 4. Assert matrix from step 3 with the produced matrix. But, I can't think of other things like - because game development is really visual. What are your thoughts on this?

Share this post


Link to post
Share on other sites
Advertisement
I'm running into the same problems. Right now I'm just checking return values and taking for granted that the desired visual results were completed. Not ideal but it's the easy way to do it. The next step you can do is to bring screenshot code into your unit tests.

Example:

1. Test rendering of scene.
2. Take screenshot.
3. Compare shot vs known good screenshot.
4. Pass or fail based on comparison. Can be binary where image is exact, or can have a threshold value, images are a certain % similar.

Share this post


Link to post
Share on other sites
Yea, but how do I get that rendering in the first place? To get that rendering I need to have code to produce it. And if that code can produce the rendering, then it has passed the test.

That seems to be coding towards a test that doesn't even exist.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I've had this discussion in another life with another game developer.

The trick is to understand what you are testing.

If you are testing your rendering engine, your unit tests should test the primitives of this engine: drawing a triangle, drawing 2 triangles, drawing 3 triangles, drawing a triangle with a light source off, with a ligt source on, with 2 light sources on, with fog, with smog, with clounds, with still camera, with moving camera, whatever your engine does.

Testing these is pretty hardcore and could go something like: render a triangle, capture, compare it bit by bit with the expected outcome (which would be a bitmap I guess).

Unit testing sequences (like a moving camera) is even trickier.

Testing it this low level might worth the effort. And then again, they might not.

After your primitives are tested (or not if you choose to skip them), the next layer of code would be some kind of model, including classes like Player, Car, Zombie, Mountain, Road, Gun, Stamina, Inventory, whatever (you do have these classes right?). And probably classes like Scene, Sequence, Timer. And then the whole shebang is linked together (by aggregation, collections, factories and such). And somehow those things get rendered.

What you want to test is not that a player will get rendered correctly with the gun in hand, but that when the Player starts, he has a Small Gun, and when he finds a big gun then he has a Big Gun.

You test that your revolutionary PathFinder algorithm will find the road to the Castle, and that that road is the one you expect it to be.

You test that your player won't be able to move forward while sleeping or dead, and won't be able to shoot it's LaserGun while under water.

These tests won't require rendering. They will simply test that your classes do what you expect them to do.

If you find out that rendering your Player with a Big Gun is broken, your next unit test should go in the rendering code not the Player or Big Gun code.

Just my 2 cents worth of it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Just my 2 cents worth of it.


Believe me, that was more than two cents :) Its a shame to see people posting anonymously with such valuable information. Anyway, thats a really nice read and has already made me realise that my testing is far to constrained (well, my ideas for testing).

I was thinking inside the box, as it were - only of the renderer. I never considered the actual game of things.

Anyway, thanks once again both for posting - I'm still up for reading more about your experiences/thoughts on this issue.

Share this post


Link to post
Share on other sites
I've done similar things for the gameplay and physics in my engine. For gameplay, I would send the gameplay classes information like:

House h = player1.buildHouse(x, y);
gameplay.Tick(0.01);
Assert(h.percentComplete, 0.005());

...

I similarly tested my physics engine by creating an envirnoment, letting gravity work, etc stepping the time, and checking where objects had moved to. This also tends to help work out any interface flaws in the classes before you try to integrate it into a large project.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement