I used to be a big advocate for unit testing, but lately, I think they are often a waste of time. They are great if you already know what you want to make and want to make sure you get-it-right-the-first-time. But if you're exploratory programming, designing as you go (which is one of the advertised uses of TDD), then you're likely to end up with 4 times as much test code as real code that all has to change drastically once you realize your initial assumptions were wrong. At that point, it's often easier to just scrap it all and start over than it is to figure out if the failed tests are because of bugs in the code or mismatches between the newer code and older tests.
I agree that TDD isn't great if you're just exploring a problem domain. For that, I use spike solutions (throw-away standalone programs).
But I've also noticed that a lot of people seem to use a very verbose, mock-centric approach to TDD. That approach isn't amenable to refactoring because anything more substantial than "rename" or "extract method" changes details that the tests depends on. If you're finding it difficult to change your code once it has tests, it might have something to do with the way you're writing your tests.
Yeah, the key is interface testing. I have a MUD that I'm writing right now with which I fell into an overly verbose TDD trap recently.
Originally, I had a script that ran an AI character through a number of actions executed via the same series of commands that a user would use, then checked the results also through the same series of commands that a user would use, and that worked great. But then I started down this road of thinking, "I never even had my own code! Look at me, granny coding, not unit testing like I should." And started down this boondoggle path of writing a few kilolines of test code.
Long story short, most of what I ended up writing was completely useless. The most important feature of testing is coverage, to have a way to hit every corner of the code to validate that it's all still "not failing", NOT to verify that the design is behaving lock-step as planned. Which is very important in this case because the game is being written in JavaScript, thus there is no static compile-time checking.
