Why JUnit 5 default access modifier changed to package-private

Question

Why is the default access modifier in JUnit 5 package-private?

Tests in JUnit 4 had to be public.

What is the benefit of changing it to package-private?

Garv

... You think that in JUnit5 tests declared as public won't work anymore? – Liturgical

The benefit is that you don't need to add public everywhere. – Mandrake

@Liturgical lol, no, I haven't written anything like this... – Garv

Answer 1

Why is the default access modifier in JUnit 5 package-private?

It's not the "default". There technically is no default. Rather, in JUnit Jupiter you have a choice: public, protected or package-private.

What is the benefit of changing it to package-private?

The benefit is that you don't have type public anymore. If your IDE automatically generates test methods and test classes for you that are public, feel free to leave them public.

But... if you are typing in the methods on your own, then just leave off public unless you are designing your test classes for subclassing from other packages, in which case you'd want to make your overrideable test methods either public or protected. And of course, interface default methods must be public.

Long story, short: we (the JUnit 5 team) believe in the principle "Less is more", meaning the less you have to type to achieve your goal, the better!

Buckshot

I'd like to provide an alternative view: In this case less typing is also less expressiveness. When I make my tests public, I express the fact that the tests are exposed to an external caller (the test framework), just like I would do if I would write a library to be used by another application. When using other access modifiers JUnit will have to use reflection to change them at runtime. While it is technically possible to leave out the access modifier, I opt to explicitly add it. Adding public for me is the best way to expresses my intent to both JUnit and other developers. – Haversine

what about our unit test class instance variables? Now that I am going down this road I want to start using the default modifier (<none>) on my mocks and other instance vars. – Airtight

thank you. Jeezz! Was reading a JUnit 5 text and came across this statement: "package protected for test methods is preferrable as it leads to less typing" -- this made me think 'typing' used in the statement was referring to type casting or such-like. And I've been trying to understand the relationship expressed in the statement since a long time. But I'm really glad to meet your response. – Hevesy

I think this answer lacks the main point of - why? yes, true, less is often more, and I believe it's not only you (JUnit team) who believes in that.. but the point is - why? and to be more precise - how? or, to elaborate a bit - why it was required until JUnit5 and why (what has changed) it's not in 5? was it just you asked "public" for no reason and now you've changed your mind? :) – Hungarian

Answer 2

This is JUnit 5 feature which produce a better encapsulation for test classes and methods

Make Jupiter tests package private #679

Test class mostly located in the same package of the class tested:

better way is to place the tests in a separate parallel directory structure with package alignment.

main/                          test/
   com/                           com/
      xyz/                           xyz/
         📜 SomeClass.java              🔨 SomeClassTests.java

This approach allows test code to access all the public and package visible members of the classes under test.

Manche

I'm not sure if this answers my question... I understand this is a feature and everything you've written is a general approach for all test frameworks. What is a benefit of having tests package-private, not public? – Garv

@Garv it produce a better encapsulation for test classes and methods – Manche

and what do I need encapsulation in tests for?? – Garv

@Garv tests are still java code (although not executed in production) – Manche

It doesn't convince me, to be honest... I can't see any benefits from encapsulation in tests... – Garv

To quote Martin Fowler: Test code is as important as production code. Give it the same level of care and attention. "this is only test code" is not a valid excuse to justify sloppy code martinfowler.com/articles/… – Quaquaversal