If you have properly architectured your code you wont need to test private methods.
For example if I have a class which is responsible for creating a blog post and inside that class I am doing some validation via private methods (like title > 10 chars, thumbnail is set) & I want to see why my tests are failing to create a post. At this point I should be separating out the validation methods to their own class. Now I have an easily testable class that does not violate the single responsibility principle.
This is another argument I hear a lot, and I don’t think it’s always that simple. Busting out a new class every time you want to test something feels like an anti-pattern. At least from a Java perspective, that could generate a lot of files which forces you to maintain some sort of mental record of what they all do.
That said, I agree with the sentiment. I just don’t think it’s always the best course of action.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you have properly architectured your code you wont need to test private methods.
For example if I have a class which is responsible for creating a blog post and inside that class I am doing some validation via private methods (like title > 10 chars, thumbnail is set) & I want to see why my tests are failing to create a post. At this point I should be separating out the validation methods to their own class. Now I have an easily testable class that does not violate the single responsibility principle.
This is another argument I hear a lot, and I don’t think it’s always that simple. Busting out a new class every time you want to test something feels like an anti-pattern. At least from a Java perspective, that could generate a lot of files which forces you to maintain some sort of mental record of what they all do.
That said, I agree with the sentiment. I just don’t think it’s always the best course of action.