A fundamental topic of discussion today with the developers I work with in my team was should we test absolutely everything in unit tests (in particular a set of unit tests for a razor page). I had a thorough thought about it again later this afternoon on it, and having read up peoples posts (StackOverflow at the like) on it, the more I thought that only tests the unit tests you need to know and have available to test.
A great quote (somewhere in StackOverflow) written that I agree with is: -
IMHO, all you should care about in a unit test of the public method is do I get the correct result. You should not care how it gets that result, only that it gives you the correct result. That way, if you want to do it a different way, you can verify that your change works by running the unit tests.
Another way to ensure that the private method "works" is to throw an exception if the public method does not get the info it needs. You could even figure out a way to make sure it doesn't work and verify that an exception is thrown.
Yes, that is true, why should we test private methods other than the fact it can't easily be done, you got to see a unit test as testing a unit of work that is made available for the user to test (something that is supposed to be testable, as mentioned to get the correct right result). If you are testing something that is a private method, you are testing something that is hidden away obscured from the developer that the user doesn't need to know.
A really nicely written that is a bit techy also more wordy but makes absolute sense is Anthony Sciamanna's article on Should Private methods Be Tested https://anthonysciamanna.com/2016/02/14/should-private-methods-be-tested.html#:~:text=Unit%20Tests%20Should%20Only%20Test%20Public%20Methods&text=In%20fact%2C%20if%20you%20are,accessing%20the%20class'%20public%20interface.
He states that it should be a no, have a read on it as it really gives some guidance and light on why you shouldn't test private methods (in a class) mainly because it breaks one of the 7 SOLID principles (mainly the single responsibility principle).
SOLID is an acronym for five main principles of Object-Oriented Programming (OOP): single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle and dependency inversion principle.
So in my honest opinion, a No to unit test everything unless it is required because it breaks mainly the above principle(s) and the code requires actual change.