I like TDD a lot and use it regularly (including today, before even reading this thread). There are different takes but my rule of thumb when using it is "don't implement a feature until you have a failing test for it." Once your test passes, you have both confirmation that your code does what you want it to and an early warning system against future regressions. Makes me much more confident that I can update things later without breaking anything, and for features that are especially fiddly (like ensuring specific password criteria, which is what I was using it for today) I find it's even faster than manual testing because you can just put a bunch of inputs and results into a arrays and not have to go through the motions of all the different scenarios.
That being said, I do find it much more difficult to apply to games than other software projects, both because (as others have pointed out) so much about what makes a game "good" is subjective, but even more so because so much of it comes down to rendered visuals which are much more difficult to automate testing for. That video on GUT had some really good info but didn't cover testing even simple things like "the PC moves to the right when I push right on the gamepad" or "the PC stops moving when they hit a wall."
