DEV Community

Discussion on: It’s Okay to Test Private Methods

Collapse
 
thiagoa profile image
Thiago Araújo Silva • Edited

I see the issue a bit differently. If you have many private methods or private methods that are complex enough to warrant being tested, it's a sign that a new module (or class, function, namespace, etc) is waiting to come to life.

That module would essentially be a private module, not a private method or a set of private methods. A new module is easier to test than a private method because the latter might require setting up unrelated stuff to put it under test, and also, some languages won't let you call private methods.

I usually listen to my unit tests: if the examples for a particular module are in great number, messy, or cumbersome, that's a sign a new module could be extracted. That's a useful code smell to be aware of.

All of that to say you are doing the right thing by testing complex private methods, and that's part of the mindset that makes for a good testing strategy, but I'd consider extracting the private methods into first class modules.

Collapse
 
renegadecoder94 profile image
Jeremy Grifski

Yeah, I saw this argument a lot when I was researching the topic for this piece. But ultimately, I couldn’t find any battle tested rules on the subject—it’s more of a feeling. In other words, when is a good time to create that new module/class?

Regardless, I’m on board. It’s hard to test a class that has too much functionality, and overly complex methods are usually a code smell. I think these types of problems have to be tackled before worrying about private method testing.