That's usually what drives people away from TDD. A very good approach for this is described at this article by Dave Hunt: https://medium.com/@davidihunt/tdd-and-complexity-1bbd5ca51e...
"Some have seen this solution to the shallow test problem and suggested that the ideal scope for our tests to target is the user interface, and to execute all the code in each test including framework and external components like the UI and the database.
Unfortunately the RoI of system testing is too low to do much of this. They’re slow, they’re brittle, they require careful environment setup and teardown, and they’re much more difficult to write and maintain than unit tests."
Slow is okay. It's better to be realistic than fast. You can also throw computing power (which is cheap) at slow. You can't throw computing power at unrealistic.
Brittle means either you have bugs which your test helpfully uncovered for you (e.g. race conditions) or you wrote a buggy test.
"Moreover, testing through the UI for every scenario in your code is just unnecessary"
It's almost always better to loosely couple your tests. It makes it easier to refactor the code that they test.