Ha! I absolutely don't mind - I'm loving it to death. My only misgiving is that I don't get much time to play at this phase in my life. But I got in an hour tonight, which makes me happy.
I really appreciate the detailed and thoughtful response. My personal experiences don't jive with that, but that's what keeps the world such a wonderful place, so I'm not going to say you're wrong.
I agree that some fields of software must have requirements that are easier to pin down and keep static than games do. But I also think "failure to figure out and pin down requirements" is commonly recognised to be the single biggest problem in software of many kinds. I suspect (but have no hard evidence) that games do not suffer especially badly in this regard. All complex projects have terrible difficulty establishing just what it is they ought to deliver. Requirements get added and changed in major ways at the last minute the whole way through, up to and after delivery - to the extent that this causes a large proportion of software projects to fail and make huge financial losses, or be abandoned. My current project, we just did eight weeks of stuff for an external client, iterative delivery, constant feedback, and then after completion last week, we find out that there have apparently been communication problems, because what we delivered is not useful to them at all. Happens all the time, at all scales.
I also haven't found in my world that doing TDD, or even just testing, makes things slower - the reason I do it is because it makes things faster overall. Again, this is difficult to prove either way without proper studies (of which there are none - the few out there are terrible, imho.) The exception to that is if the team is inexperienced at testing, or when trying to retrofit tests in the middle of a project that was written without them, or has low code quality. Then I agree it really does slow you down.
I think if I were to list the benefits of TDD, in order of importance, then the top entry would be that it enables rapid and ruthless refactoring, followed perhaps by the correctness verification that the tests bring. So in my world, a project which experiences a lot of churn - requirements constantly changing, designs being ripped out and replaced - is actually the very best place to use TDD. The payoff is actually lower on a project with clearly understood and static requirements.
The argument you use about covering every possible permutation of state and input being untenable is one I've heard a lot, in all fields of software, but I think it's mistaken, because I've seen counter-examples in which it has been done, to great effect. Those were actually the highest-functioning teams I've ever worked on, and I think the causality is in the direction of "tests made the team high-functioning", not the other way around. There are techniques to slice large phase spaces down into manageable parts.
I'm a coder, but not a game coder. I work in military radars, geospatial stuff, some startups. I've dabbled in weekend or week-long hobbyist game projects, which I enjoy very much.
I'm currently on a one-man crusade to demonstrate Python as a viable gamedev language. I'm happy that even with my Sunday afternoon dabbling, I can get hundreds of independently positioned/oriented meshes rendering at 60fps even on an old, modest laptop with Intel gfx, with some behaviours in place, so that's plenty for my purposes. :-)