-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: