Allow fields, methods, and constructors in Jupiter to be private

[rmannibucau]

Hi,

In java there is no real reason to support package scope member but not private ones so let's drop that constraint in next release please.

Romain

[sbrannen]

Which type of field are you referring to?

[sbrannen]

Based on a quick textual search in the code base, I assume you are referring to @RegisterExtension fields, but a confirmation would be appreciated.

[rmannibucau]

@sbrannen yes but guess update must be more general on all members (thinking to TempDirectory too), @BeforeEach/@AfterEach etc...IMHO opening the "not public" door should mean enabling all until "private".

[sbrannen]

Thanks for the feedback.

We've intentionally not supported finding private fields, methods, etc. since the beginning of JUnit 5, but I suppose we can discuss it again amongst the team.

---

Tentatively slated for 5.8 M1 solely for the purpose of team discussion

[marcphilipp]

Team decision: We support package-private methods because they're shorter to write and are in accordance with the convention of placing test classes in the same package as production code.

[rmannibucau]

Side note: it violates several style validations and common practises in terms of visibility (why Test2 can check Test1 extensions?), in particular when integrating with 3rd parties (which almost all allows private injections) so overal it makes the test class inconsistent. Any hope it gets revised with wider scope than just junit scope?

[marcphilipp]

What violates style validations?

[rmannibucau]

@marcphilipp cause it is common to enable private fields and forbids protected or package ones due to the leak it does (regarding encapsulation). In other words it means your test style can't be your main code style (mixed with nested test classes it starts to becomes hard to validate but even when physically split it not not good to code differently depending folders of the same project IMHO).
More techincally, on an IDE point of view you get completion from friend classes which is also a noise you don't desire when writing tests IMHO.
Hope it is clearer written this way.

[marcphilipp]

IIUC you're mostly concerned about fields not allowed to be private with @RegisterExtension?

[rmannibucau]

@marcphilipp yep, funnily I was not "hit" by that on methods (guess rules I used are not very strict for methods).

[marcphilipp]

I can understand your use case but it would be inconsistent to allow private on fields but not on methods and I really don't want to allow it for methods. 😕

[rmannibucau]

@marcphilipp I can understand that as well. How about an engine parameter "allowedVisibility"? I know it is a toggle but not a crazy one IMHO.

[marcphilipp]

At this point I don't think it's worth the added complexity.

[rmannibucau]

Fun thing (not sure if "fun" is that right ;)) is that if you drop the "if private fail" check it works on private fields :(.