I don't think you understand the significance of the word "driven." Coding something and then testing it is not TDD. In TDD, you don't write any application code that a failed test doesn't demand in order to pass—and even then, only just enough to make that test pass, even if it just means alwars returning 4 from a rand function.

Of course, a "play test" is not an unit test, or an integration test (and is only mildly similar to an acceptance test.) Playtest-driven development would be an entirely new affair, likely involving gameplay freeze-states and kept in version control, and a constant numerical analysis for the player's emotional state (perhaps using some sort of face-recognition) given alternate code paths.

Not quite the same thing, you are talking about QAing the product.

Test driven development or more simply unit testing code, is writing automated tests that ensure your code at the smallest unit you can access ( e.g. a single method ) is doing what you expect under all conditions.

See: http://en.wikipedia.org/wiki/Test-driven_development and: http://en.wikipedia.org/wiki/Unit_test

That's barely even testing, and it's certainly not TDD. If I play through the feature I just coded or the bug I just fixed, I can verify that it's doing what I think it's doing, but I need outside verification that it's correct. In effect, I can verify my code's precision (it's doing precisely what I told it to do), but not it's accuracy (if my idea of a feature is inaccurate, my own testing won't catch that).

That having been said, TDD and automated testing can definitely make some headway into game development, but there are a whole host of challenges and questions to surmount there, especially for code-bases that are going to get stripped down to bare-bones every 1-3 years for a new game, if they get reused at all, so the tolerance for hacky code is quite a bit higher.