I don't think I've ever heard TDD talk about incremental steps, it's always been the focus on at the unit level.
I don't have an example at the moment, this is mainly from my last job where I couldn't figure out how to fit TDD in for new features. It was still very much a start up in how the day to day went so devs were given a feature to implement and that was it. Aside from the requirement, there wasn't even a function to call so you couldn't really write a high level test at the start.
You seem to be confusing unit testing with TDD.
Unit tests are one type of tests, the bottom layer of the Test Pyramid, which also defines the Services and UI tests.
Whereas TDD means Test-Driven Development. Simply put it says that you should write a test first, and only then you should write the code to make it pass. After that, you should refactor, add a new assertion (requirement), making it fail again, and write the code to fix it. It can be any kind of tests. An integration test that talks to a 3rd-party system, a unit test that mocks all external calls but asserts that the inwards of an endpoint behave properly or an automated UI test that validates user input and the error message display feature.
It seems people these days have not read Test-Driven Development. They end up getting to know TDD from different places, with different levels of adoption, etc. I highly recommend anyone to read it. It is simple, clear and small. And on top of that is super effective. I usually name it as one of my career-changing books (the other one being The Agile Samurai).
This is all good - one quick clarification: a Unit test does not necessarily test a function/class/object/whatever.
It tests a unit of behaviour.
TDD does not mean adding one test per function/class/whatever. It should mean writing a test that describes the behaviour of your program, and then writing code that implements that behaviour.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.