I would argue that those people are wrong, and defeating the purpose of object oriented programming, by braking a couple of basic principles like encapsulation

I 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.