You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so – for example, when a test class is extended by a test class in another package. Another technical reason for making classes and methods public is to simplify testing on the module path when using the Java Module System.
(Emphasis mine.)
I remember that in the past an opens my.pkg; directive was required in the module-info.java file was required to execute package-private test classes/methods residing in that package.
Recently I removed such an existing opens and expected some package-private tests to fail – but they ran successfully.
With a recent JUnit version, what does "simplify testing on the module path" mean?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
From the documentation:
(Emphasis mine.)
I remember that in the past an
opens my.pkg;
directive was required in themodule-info.java
file was required to execute package-private test classes/methods residing in that package.Recently I removed such an existing
opens
and expected some package-private tests to fail – but they ran successfully.With a recent JUnit version, what does "simplify testing on the module path" mean?
Beta Was this translation helpful? Give feedback.
All reactions