Contents
Why shouldnt you test private methods?
The short answer is that you shouldn’t test private methods directly, but only their effects on the public methods that call them. The test should only be accessing the class’ public interface. If an object is hard to test via its public interface, it is going to be hard to use in the production code.
Should we mock private methods?
Mocking techniques should be applied to the external dependencies of the class and not to the class itself. If mocking of private methods is essential for testing our classes, it usually indicates a bad design.
When to test private methods in a class?
Proponents of indirect testing of private methods argue that you should only test the public methods of a class. If the public methods make use of private methods, then these private methods automatically get tested when the observable results of the public methods are checked.
How are private methods tested in test driven refactoring?
Private methods are only created as the result of a refactoring step. And the path of code going through the private method is already being tested by previously written tests. So, after successfully doing TDD, your code will not have specific tests for the private methods.
When do you test private methods in TDD?
When really doing TDD (i.e. writing the test code before writing the functional code, and then refactoring the code) private methods are guaranteed to be test covered. When driving the functional code design and implementation from the unit test (aka Test Driven Development), no method is created private.
Can a method be unit tested with a private modifier?
It is also too complicated, especially given how easily the methods can be tested if the private modifier is dropped. By removing the private modifier, the method is visible in the package of the class, and nowhere else. This means that the method can now be unit tested (provided that the same package is used in the test class).