You generally shouldn't test private members directly.
You should be testing that your implementation meets it's interface by writing tests that use your code as normal.
This is what TDD means when it says that "testable" code is well designed code. If you find yourself needing reflection in order to write tests, your code is not testable (and thus possibly needs better design)
If using your code requires inkoking t private members, they shouldn't be private. If you don't need to invoke private members to use your module, then neither should your tests.
For example, via inversion of control / dependency injection, you can guide the unit under test into whatever state you want by passing "fake" implementations of its dependencies which, for example, trigger error conditions. This also leads to production code that has more separated responsibilities that is easier to refactor (or delete!) since
your code does fewer things in each place.
This is a highly opinion-based topic, if you should or shouldn't test private/protected methods, just see the discussion here: stackoverflow.com/questions/105007...
I agree with the concepts you mentioned, but in some cases, especially when working with legacy code, creating unit tests for those methods could be beneficial. Also the tests can ensure that you don't make breaking changes in private methods.
The stackoverflow link you posted shows that the winner of the discussion (marked as accepted and higher votes) is the answer that tells you NOT to test private methods.
If a private method is changed, the tests for the public methods should pick it up, via a difference in the expected output of the public methods that use the private method.
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.
You generally shouldn't test private members directly.
You should be testing that your implementation meets it's interface by writing tests that use your code as normal.
This is what TDD means when it says that "testable" code is well designed code. If you find yourself needing reflection in order to write tests, your code is not testable (and thus possibly needs better design)
If using your code requires inkoking t private members, they shouldn't be private. If you don't need to invoke private members to use your module, then neither should your tests.
For example, via inversion of control / dependency injection, you can guide the unit under test into whatever state you want by passing "fake" implementations of its dependencies which, for example, trigger error conditions. This also leads to production code that has more separated responsibilities that is easier to refactor (or delete!) since
your code does fewer things in each place.
This is a highly opinion-based topic, if you should or shouldn't test private/protected methods, just see the discussion here: stackoverflow.com/questions/105007...
I agree with the concepts you mentioned, but in some cases, especially when working with legacy code, creating unit tests for those methods could be beneficial. Also the tests can ensure that you don't make breaking changes in private methods.
The stackoverflow link you posted shows that the winner of the discussion (marked as accepted and higher votes) is the answer that tells you NOT to test private methods.
If a private method is changed, the tests for the public methods should pick it up, via a difference in the expected output of the public methods that use the private method.