Depth First vs Breadth First programming and stubbing

Originally I wanted to title this saying TDD instead of stubbing, but really the reason this topic came up is due to chatting with a friend about writing dummy functions to get TDD to pass, which lead to me commenting that sometimes I want to stub something out so I can say "well let's pretend that works" and move on and get the code I'm actively working, on working.

Breadth First Programming Style
This style of programming is writing the highest level (user facing we'll call it) code first, any calls to functions that should do something or get data or whatever should be quickly written as stubs with something to get you moving in your current function. The next step is moving into the first (or last depending on the order you'd like to go) and managing that functionality. If that calls down into nested functions then you follow the same organization, finish all the functions at the n-1 level of your earlier function and go on.

Depth First Programming Style
This style of programming is writing code that always works at each step. If you start writing and you come across a function you need, you simply drop down and implement it, and if that has functions it calls, you do the same. This keeps happening until you've finished everything down to the bottom, when you move up you do the same thing on the next function until you finally reach the top level and move along again.

Mixed Style
I like to work in a Mixed style. When you're working a complicated algorithm on your main thread of work it makes sense to say, well lets assume we get this data correctly and move on and continue working the algorithm, however if it's a relatively easy problem to solve and dropping into the function the function is a bear, it might make more sense to just implement that function first then move back up to your higher level.

TDD Aside
Since I brought it up I should talk a little about TDD. TDD is to me more of a Depth First style of programming. You write up a test, then you implement a high level of it, and yay it passes, then you write another test and drop back down to the function level you were at and "fix it" and keep doing that. I almost would compare this to a Yo-Yo strategy, you start at the top with a test, and throw your Yo-Yo, then when it gets all the way through the pass you start again at the top. You don't move forward until things are as right as you can make them.

How do you work what is your style? What do you think TDD is like? Are there any other programming styles you can think of  in this context?