3 ms·
> private methods should be executed and thus indirectly testable by public methods. Many people would count that as integration tests. Because if you don't ca
by loup-vaillant 9y ago
> private methods should be executed and thus indirectly testable by public methods.
Many people would count that as integration tests. Because if you don't call the method directly, it's not a unit test, for some reason. (I guess it depends whether you consider the unit to be the class or the method.)
Some of those people will also say that not being able to "unit" test a method is actually a bad thing. I personally don't care much, as long as I can make sure the code works somehow.
- kolme 9y agoI would argue that those people are wrong, and defeating the purpose of object oriented programming, by braking a couple of basic principles like encapsulation and abstraction. Also, they are wrong in that they also defeat the whole purpose of unit testing, which is being able to refactor with confidence that there won't be any regressions. If you "unit test" the private implementation details of a class, you'll need to fix the tests every time you want to refactor it. That's an unacceptable tax. Instead, classes should encapsulate and abstract away a problem for you, from the outside, you shouldn't need to know how it works. It should expose a clear interface ideally as loosely coupled to other classes as possible. And this interface is the bit that needs to be unit tested, the "contract" with the outside world.