Recently I started developing a parser and some classes around this project. Since a parser can be very complex and I like to start coding with a vision (how should the class be used later on; write some sample code without the class actually existing), I wrote a test (instead of writing a small program). So I wrote a little bit of code and checked if it did what it was supposed to do. What I recognized is that working this way structured lead to code that had a lot of small functions (yea Clean Code) and let me recognize some places in older classes that weren't working correct because I had no tests for the yet. Basically it worked like this: write my dummy code. Write some code that should do what the test expected and tried it. Wrote another test...
When I found an error, and here begins the interesting part for me, if that error did belong to another class I first wrote a test: how should the class behave in that case. Solved that single problem and continued with the previous test I was actually trying to fix. So not only that this led to a lot of tests that actually did something useful but also to good names for the test (because I knew what I wanted to reach) and to much more smaller functions in the implementation. It was to reduce work for me. There were methods that had special implementations because of performance. Since another feature was not really well integrated in that code I threw it away and reused the working version. Yes performance might not be best for now but since I have a lot of tests for the method I reused I can be sure it is working and I when I will move to another implementation I just add the tests which currently test the reused method.
What I recognized: there is no need for perfection. When I tried TDD earlier I often found weird code examples and thousand of small small test. In theory you might get almost 100% code coverage but the way you reach that is often too complicated for my daily work. I loose focus on what is important. I think of how to decouple and so forth without it being really necessary for the actual implementation. Not ever part of a software must be exchangeable NOW. So my way of writing tests is:
I use a unit testing framework (I like it simple; xunit in rider was easy to implement)
Test my classes integrated (input parameters lead to specific output parameters)
When I am sure that a specific input will not be given I don't need to test it. If am unsure I either prevent it via code (check your parameter values) or write a test. I try to keep things like SRP in a healthy way. If my test for class A partially tests class B that's fine. The detailed tests will be part of the test class for B, not A. I might later add cases when I find errors were A and B do not work together as expected. Same for methods.
That way you test what you need now. Still reach your goal (get work done) Keep your focus and have a high code coverage. It actually was kind of fun to work that way.
