I'm not a game programmer but I am a commercial systems programmer, and automated unit tests are now stock-in-trade. We tend to use the tools in two ways (we use C#, so nUnit or MSTest are our toolkit)
1) To investigate the behaviour of a unit of code when writing it - code the test alongside the unit. You end up doing far less debugging step-through type stuff that way.
2) To formally test the boundary conditions of the code to make sure critical sections (like multithreaded code) works as designed, and in a way which would only be evident at runtime.
Both styles of tests are checked in to the source code control system at the same time, and we pump out statistics that give us code test coverage with each build - if it falls below a certain percentage we start to get twitchy - but there is no set limit. Typically code which is both complex (cyclomatic complexity) and not covered by unit tests, is flagged as being a hotspot and we then pick up some additional testing.
In my experience, and having come to automated testing late, I wouldn't now code without it. You dont actually need a unit test toolkit since these are just harnesses that allow you to execute a single portion of your code - you could do the same with a parameterised command line application if you wanted to. I'm not dogmatic about TDD - but in my experience programmers work faster and more accurately if they write unit tests at the same time as their line-of-business code. Its actually cheaper, and not just in the long run - any project greater than a couple of days will be made more accurate and more timely if the programmer codes tests at the same time.
As an example in the game world, in my hobby terrain project, I used unit tests to isolate and explore the behaviour of my mesh clipping and frustum culling, to make sure it was behaving as I expected. It also means I can semi-confidently change a portion of otherwise complex code, and use my unit tests as a "trigger" to spot any changes to external behaviour that I didn't know about. At its most extreme in the commercial world I've seen a big drop in the amount of paperwork specifications and "explanatory" documents needing to be produced by programmers - although this outcome isn't the goal, the fact that the behaviour of the code is explained in a series of unit tests does help incoming programmers.
The last thing to say is that using automated unit tests leads you to write better code - not just less bugs, but more structured, more isolated and more open and allows much more confident maintenance of complex systems, and less time spent in marathon debugging sessions.