-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document best practices for test method and test class visibility #2626
Comments
Tentatively slated for 5.8 M2 solely for the purpose of team discussion. |
Team decision: Add another sentence:
|
I'm not sure if this was considered, but I thought I would mention it for anyone who comes here (I was myself linked here). When testing on the module path, using non-public test methods requires opening the test packages to JUnit 5. I find it easier to export the packages (Maven Surefire does this automatically). That's my personal reason for using public test methods at the moment, but this could change if a later Surefire version opens packages. For reference, here's a Maven surefire issue which describes the error one might encounter using non-public test methods: https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1909 |
@A248, I think that's a good use case to mention in the User Guide, since it might assist some people who encounter that issue. So I'm reopening this issue to add a hint about that as well. |
This is a follow up to 419ddb1. Closes junit-team#2626
Closely related to: |
In JUnit Jupiter, the
public
modifier is optional in test classes and methods.I see test classes in JUnit, Spring projects, etc apply this no
public
modifier pattern.Once I get used to this style, it feels very redundant when I encounter tests that have
public
all over.I believe this is a good practice to follow.
However, in JUnit documentation, I only find this line regarding the
public
modifier:It would be great if JUnit documentation mentions that leaving off the
public
modifier is preferred unless visibility is required. (e.g. base class shared by different packages)I understand this is a bit of opinionated aspect, but it would be nice to mention the principle of "less is more" in the documentation.
So that, a person like me can encourage this pattern to other devs with the backup of JUnit good practice.
The text was updated successfully, but these errors were encountered: