TDD. I have quite complex coding exercise, do I test private methods if they are very complex?
So my class only exposes one public method, but contains few very complex methods, which should be tested I think?
there is doubt: do I test them or not?
Asked
Active
Viewed 173 times
-1
-
What do you mean with *"my class only exposes one public method"*? How do you know? Aren't you writing the tests first? – Mark Seemann Mar 23 '16 at 07:54
-
I am about to rewrite it as an exercise. – Prostitutor Mar 23 '16 at 08:18
1 Answers
5
If you're doing TDD it should not be physically possible to come to a point where you have "very complex" private methods. The third stage of TDD is "refactor". When you implement features, you constantly pull stuff apart, break stuff out, extract methods, classes, etc., all so you can avoid ending up with god objects that do 100000 things in arcane ways.
When dealing with such classes in legacy code (that is a topic one can write whole books on (and people have)), it's generally thought of as good practice to do the bare minimum amount of refactoring required to make the code at all testable (without resorting to reflection and similar ugly hacks). Then you cover the code with tests until you feel fairly confident that you can start to make changes to it without breaking the contract.
At this point you can start to refactor, break stuff out, extract and go crazy until you have something more managable.
The bottom line is: no, do not test private methods. It makes for brittle tests that are hard to understand and it will only serve to cement bad design, rather than help you get a better design (one of the explicit goals with TDD).
Even if you think "well it's better to get the coverage fast now and I can fix it later", no, it's not worth it. It's a huge technical debt that you WILL NOT REPAY in the next 10 years. It's just too much of a bother.
sara
- 3,521
- 14
- 34