Lets take your jump method as an example: You tested if the player jumps. What if the player now does make an attack while in air and jumps again? Are animations well-playing then? There is a lot you have to consider which would make the tests rather bloated. That’s why you invite some testers over. They see what the computer won’t see until you’re so genius and implement a ingame Kinect >.>

I definitely agree that TDD applies really well to API, helpers etc, I think there is also validity in testing gameplay. The tests will certainly take a different shape and will serve a completely different purpose. Rather than just testing validity of the code they will serve as a pseudo-design document outlining how the designers expect their game entities to behave.

Good call on the issue with my example. I’ve updated to include a call to Update(). I left this out originally for clarity but in doing so I’ve created more confusion .

“I guess you could pre-calculate his trajectory if you were using simple maths for your character movement, but what if you’re adding acceleration over time to his jump (your own physics)?”

This actually leads into an interesting topic I’ve been thinking about lately. I’m a big fan of deterministic movement in games (specifically that at any time x, you know exactly where every game entity will be). I might even write my thoughts up in a future blog. The need arose when I was thinking about having tens or hundreds of thousands of game entities in a multiplayer match.

“Perhaps in these cases you need to write extra code specifically for the test? Doesn’t this mean more maintenance?”

You are correct that TDD will require a lot more code. Some put it in the order of 10x more testing code than actual production code. This is one of the reasons people don’t like TDD. From experience though, I find that the confidence and testability gained from the code easily pays for itself. It does bring up the interesting point of what happens if the test’s themselves have bugs

Take your example of Mario. Everything in that example is fine, except for the mario.Jump(Right);

Normally you’d map that to a key, press the key and it plays out over multiple frames. Wouldn’t you need a specific function that tests Jump in this way as opposed to directly calling it? I.e. you need to block that call till the physics finishes for the test case, but during the game you’d just call Jump and immediately return, letting it play out over several frames.

I guess you could pre-calculate his trajectory if you were using simple maths for your character movement, but what if you’re adding acceleration over time to his jump (your own physics)?

What if you had a physics system using dynamic rigid bodies and adding forces? You’d need to let it simulate for a while until you know he’s done jumping.

Perhaps in these cases you need to write extra code specifically for the test? Doesn’t this mean more maintenance?

Just some thoughts

Cliff