I'm new to TDD, and relatively new to software development in general (e.g. < 4 years experience), but I am trying to learn.
I have been toying with TDD but ran into what I know realize is a common problem. I have been testing both higher level API contracts, sometimes with integration tests when necessary, and lower level implementation dependent unit tests.
I recently watched a talk by Ian Cooper who suggests that we should not test internals, only what the intended actual functionality of the program (e.g. whatever the contract of the program is). Note that I am paraphrasing here, and may have missed the message.
It makes sense to me that it would help by allowing to refactor without worrying about tests that break the internals, but at the same time it feels weird not testing a lot of the internal functions (private or not) that I write to help me achieve the bigger functionality at hand. Furthermore, sometimes if I try to write tests that only test at a high contract level, the tests become too large/complex.
Also doesn't this contradict the major push for tons of unit tests and that in general the more unit tests the better because they help us identify the specific problem when they fail rather than being omnibus?
How do I balance this? Is it just a balancing act that I will learn over time through experience?