Why private access for methods is more preferable than package-private?

Question

Java developers always use private access level for methods which are not used outside of this class. There are known benefits of doing so but from other side we increase complexity of unit tests. In most of cases our code is not used by any other services/APIs and we actually don't care of 'private' benefits. But what I believe we do care is to create readable simple unit tests. Considering this, why do not create all methods in class as 'package-private' by default and make them 'private' only in case when we really need this?

Answer 1

Why private access for methods is more preferable than package-private?

I would not say that it is preferable.
Both practices are acceptable and don't shock me.
Now private should be favored as much as possible as it prevents undesirable coupling while package-private that creates a little more coupling should be used with relevancy.

In most of cases our code is not used by any other services/APIs and we actually don't care of 'private' benefits.

Even as you develop a library to be used by some clients, using the package modifier is not bad as the classes in the package-private doesn't make part directly of the API.

But what I believe we do care is to create readable simple unit tests. Considering this, why do not create all methods in class as 'package-private' by default and make them 'private' only in case when we really need this?

Reversely, unit testing and private modifiers are not incompatible at all.
I agree that using package-private modifier instead of private allows to test/mock/switch easily members of classes.
In some cases, this practice is acceptable.
Now generalizing this is before all a design choice.
Personally I use the package-private modifier only as really relevant (a real issue for testing or a internal processing to share among other classes of the same package) because beyond making unit testing easier (which is a good point), I think that this kind of practice may favor a design that couples the classes more strongly than required.
For example, suppose in a B class you may access a field/method of a A class instance because these are in the same package.
Suppose that conceptually this field make part of a very internal part of the A implementation and that it have not be known by other classes to allows to change it later.
But as this field/method is package-private, now nothing prevents you from making it as you can.
I don't like that.

To finish, I would say that you should not worry about unit testing of private methods.
Internals don't make part of the API. You don't need to test it.
Now if the private method is invoked multiple times or you really need to test this processing, nothing prevents you from extracting it in another class to make it testable and to have a way to mock the processing if required (to avoid test it multiple times).