0

When practicing extract and override refactoring, I often examples of very skilled coaches and trainers where the access modifiers of the extracted method is changed from private to protected. 

protected CollectResultReader loadRecordFromOutFile() {
    return CollectResultReader.factory("../record.json");
}

In the example above the code was extracted, the IDE created a new method with a private modifier in the target code. That is desired behaviour. In order to be able to override the class under test, it was reedited being protected. That is undesired because it means that the production code lost its readeability and gained unwanted access.

Please note that I want to use pure Java and no mocking framework. I keep my Unit Tests in a different path in the same package.

My question: Why not make the method package private (no modifier)?

See the package private modifier in: Controlling Access to Members of a Class

otembajelle
  • 166
  • 2
  • 12

1 Answers1

0

As long you can keep the test class in the same package, there's no reason to make it protected. Package private is enough.

I've been working in projects, where I was forced to make them protected. The reasoning was that package private is not something an avarage java developer knows about.

BetaRide
  • 16,207
  • 29
  • 99
  • 177
  • Thank you BetaRide, that confirms my guess. I wondereded why the gross of developers avoid package private, it made no sense to me. – otembajelle Nov 27 '16 at 10:16