If you write tests first, you don't write a complete front to back "thread" first, right?
If you write tests first, you assume that the test is going to match how you're going to use the stuff in a real situation, which you generally don't know.
That complete front-to-back 'happy path' test is exactly what I would normally start with as a first test, and it should of course be representative of how you are going to use it in a real situation.
Not sure what kind of tests you write if they don't represent the actual expected behavior?
You don't write production code unless there is a need for it.
The need is documented in a failing test case.
Where does the failing test case come from?
Hopefully from some other part of the code needing that code to be there. Or are you just conjuring up test cases out of thin air? If you're doing that, I'd venture you're not doing TDD.
And certainly doing a spike to get the lay of the land is very mach part of XP where TDD came from.
As is slicing your system vertically, so complete units of functionality within an incomplete system.
Rather than slicing horizontally, which is what you seem to be doing.
If you write tests first, you assume that the test is going to match how you're going to use the stuff in a real situation, which you generally don't know.