Skip to main content

Test Internals with TDD? [Resolved]

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?

Question Credit: Adam Thompson
Question Reference
Asked March 10, 2018
Posted Under: Programming
2 Answers

If the internals of your class are so complex that they require thorough testing, then your class is violating the SRP (doing too much). Refactor it into a client of a new external utility class, and test that utility class separately.

credit: Kilian Foth
Answered March 10, 2018
Your Answer