[matsemann]

Game code can be hard to unit test, it needs integration tests on actual hardware. Lots of weird stuff on all chips that need to be taken care of.

[moron4hire]

There's also no easy way to test for things like "do the shadows render correctly".

About the only thing you can do is take before/after screenshots and compute a signal-to-noise ration on a diff between the images. Which makes for an extremely fragile test definition. What if you change the default FOV of the camera? Now all your tests fail for no good reason.

[andor]

What if you change the default FOV of the camera? Now all your tests fail for no good reason.

Which is completely fine, because you probably wouldn't want to accidentally change the FOV, would you?

High confidence tests fail on unexpected results. If only some aspects of the results are checked, the tests have obvious blind spots.

[daemin]

Yep, lots of interaction tests that can be quite brittle and can take a long time to run, even with a farm of servers and consoles.

A lot of small and low level stuff can be unit tested but during production things like writing good tests falls through the cracks.

[bogwog]

And game development usually involves a lot of iteration, so setting up tests is at best a waste of time, and at worst a crutch that hurts productivity.

[daemin]

The best benefit we've found for unit tests is in low level platform specific code and generic containers. Things of that nature which absolutely must work and can themselves be tested in isolation.

I'm sure when we finish the project and look back on it we can go in, clean up, and implement far more unit tests for the code we already have.