If you fundamentally don't understand TDD, of course you will have poor results. The main point of TDD is to drive the DESIGN (that's what those 2 ds stand for). You write the test first to help you think through the best design and build it in the smallest increments possible. With that, you get a fast feedback loop that lets you know each small piece of code works, vs. having to build enough code to run the full system (and bootstrap/run it every time you make a change).

Having tests that document the code and catch regressions is a nice side effect, but it's not the goal. Mocks allow you to set up a specific state that is likely to occur in the system and develop for just that piece. If you have a lot of real code that's bootstrapped and a test fails, there are a lot of different places the problem can be. If a component only has 4 paths through it, it doesn't matter how a dependency that exercises one of those 4 paths comes to be in that state. You don't have to exercise the code to put the dependency into that state for the test of something that uses the dependency. That's the point of SRP, and if you're having a problem with that, likely you're reaching out and grabbing your dependencies from inside your code vs injecting them.

If you're making a change to your system, likely there's a reason for it. At LEAST one test SHOULD change if the change is significant--otherwise leave the code alone. So it's silly to complain that changes in implementation break your tests. If changes in the implementation of dependencies break the tests where you're using those dependencies--well, there's your problem. Likely they wouldn't if you developed test first, because it encourages you to design your code in such a way that doesn't happen.