Instead of just writing a class with a bunch of methods that seem useful, you write the tests to figure out what a user actually needs, and iterate on that. And as a wonderful byproduct, you get a suite of regression tests so you can comfortably refactor and add features in the future.
It's explained right there on the cover Test *Driven* Development. Not a testing method. A development process guided by unit "tests". In quotes as unit tests are at least 51% about forcing you to write small, isolated blocks of code with well defined and simple interfaces. Units. A large percentage of remainder is enabling ruthless refactoring (refactoring being a huge part of TDD's development practice/philosophy) by ensuring you have not violated those interfaces. Only a few percent is actually about having "correct" code.
IOW, you will never have your bottom layer done correctly or completely.
At some top layer you're going to think "well, looks like I won't be need that function", OR, "Well, looks like I am missing a function for $FOO"/
It's the premise of On Lisp, for example, http://www.paulgraham.com/onlisp.html
I'm not saying it never gets fixed, I'm saying it's extra work compared to top-down.
Top-down produces only and exactly what is needed to get the current layer to compile, run, and pass/fail.
Bottom-up requires that the bottom-most unimplemented layer be written to provide at least what the next higher level needs.
And since you cannot predict that perfectly all the time, you will have to come back and refine (not refactor) that layer: remove some functionality that turned out not to be needed, or add some other functionality that turns out was needed.
This step is never going to happen in a top-down effort.
[PS. At work I've almost always done bottom-up, because that suits the workflow constraints better: 1) Never leave commit a non-working build, 2) never do a PR for an incomplete module, 3) Always make PRs as small as possible, etc.
For my own projects/hobbies/experiementation, I used to do the same thing. Now I'm experimenting with the top-down approach and my velocity is a little faster because I am never spending time removing stuff that was written.]
We're using this approach in trading production system for about 5 years now and I recommend it, works very well.
There is also side effect where your dependency tree is more shallow.
> We're using this approach in trading production system for about 5 years now and I recommend it, works very well.
I haven't worked anywhere since 2004 that used any other approach; it's the dominant approach to development - commit code, starting from the lowest layer to the highest.
My experimentation thus far using "commit code, starting from the highest level to the lowest" has been more satisfying to me in terms of velocity.
Some might call that thing a 'narrow waist' but I don't quite equate it to that although it's a good example. Is the thing you want a stream of bytes, sequence of messages, unsequenced messages, or priority-ordered messages?
The problem with bottom-up is that you don't know the context. The problem with top-down is that you do know the context--and can leak it into what should be without. I find the latter works out better if you're aware of avoiding it. How do you avoid not having context without going top-down?
An analogy in UX would be Windows vs Mac. Windows builds things then puts the UI on what they've built--in many different kinds of settings places. Mac figures out what information & controls the user should have and how to name and group them.
Edit: I actually have a recent real-world example. Making a subsystem for querying and mutating things, what they are doesn't matter. We set out making an 'adjust' operation and a 'move' operation because we wanted to preserve paired decrement/increment amount for moves. We were also certain that we only needed to move between two things, or adjust many things but only of one kind. We got all the way up to the top where the public API was getting close to complete. We discovered use-cases that made sense to to more than those operations. We were able to shuffle things around and ended up with a fully-capable 'adjust' operation that can work on any number of kinds/things, and a fully-capable 'move' operation that can work on any number of kinds/things. On top of that we added checks to only do what we need now. The more general things were substantially harder to make work efficiently which is why we chose not to do it when we were sure we didn't need it. We were wrong.
You know the context. You have the whole problem in front of you. The question is about which direction you're going to solve it.
For "you want a stream of bytes, sequence of messages, unsequenced messages, or priority-ordered messages?" the answer is you probably want type parametrized iterator at this level if you can ask this kind of question.
To put it in other words you put more attention into trying to find underlying composition of algebras in problems than doing adhoc, inlined imperative constructions littered with if statements that you add every time some issue is discovered.
I've repeatedly, throughout my devlog, emphasised that I'm calling functions that don't exist, then I create stubs of those functions (a one liner returning an error), then I populate the stub with actual logic.
To me, this is the most natural way of writing code.
But the one thing I can't agree on is that teaching them TDD is either necessary or sufficient for them to start thinking about that. I'm pretty sure that if you can manage to write code without knowing how it will be used, you will write tests that way too. Writing a test doesn't force you to think about your API any more than writing the API.
There's no fast and hard rule, I'm afraid.
And tests that describe how an API can be called are BDD. Hold the Cucumber.