--> The "hello-world of TDD" typically involves a small class with some functions and some unit-tests. A good base to explain things. It also gives a framework to explain many tools and concepts like mocks, stubs and test-drivers.
Often, the next step is: using more and more tools, better and better concepts and many more details. The pitfall: all those little, important details hide the big picture.
What is the goal? And what flaws do we want to prevent?

As most programmers know, many errors found in real-systems are no "bug"; 80% of them are introduced 'pre-coding'. Even 'perfect code' with 100% test-coverage still contains 8 out of 10 flaws. Because the requirements are plain wrong, the architecture doesn't fit, or the design is misleasing. Isn't the better question how to prevent these 8, instead of only focusing on that 20%?

And by the way; what does that mean 100% coverage? That is another strategic question.
Can you estimate the number of test-runs you need to fully test 1 function, 1 class, or 1 file? And does your approach scale to big, complex systems? Where some code may be coupled to other parts, via electrical or other -physical- ways?

My (personal) view is that you, as a programmer, should take responsibility to deliver flawless: code without bugs, AND operating as expected. If you don't, who will?

TDD isn't only about less buggy code. Development implies "designing" - "architecting", too. TDD aims to prevent 80% of the flaws even before you start coding!
This implies you'll start coding a lot easier!