It seems that TDD is not the best approach to design such framework. When you expect your api change frequently on early stages, tests may be trhown away wery fast and be useless. So it's better to delay writing tests for time, when api becomes stable more or less.
You need to know what to test before actually test.
I've found that TDD is pretty crappy for exploratory development on things like frameworks. It's much easier to test once I've hit the point where I know how everything should look and behave.
Yeah, in my own experience TDD makes a lot more sense when you have something substantial built.. like say version1 of a product. Doing TDD from the scratch is a lot more hassle without substantial gains
Ya, the biggest issue is that it makes tacking on tests a lot more tedious/challenging. You have to Crete the seams where TDD evolves them via API.
I generally agree with the notion that "exploratory spikes" are much needed. The trick is to toss those in the rubbish bin and TDD the real API. Bet of both worlds.
I can understand the lack of documentation, but I balk at the fact that framework developers wouldn't use TDD to guide the development :(