Skip to content
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

Allow @Rule annotation on non-public fields #31

Closed
mknittig opened this issue Oct 4, 2009 · 4 comments
Closed

Allow @Rule annotation on non-public fields #31

mknittig opened this issue Oct 4, 2009 · 4 comments

Comments

@mknittig
Copy link

mknittig commented Oct 4, 2009

I really don't see why fields with a @rule annotations must be public and it's quite easy to fix...

@Yishai
Copy link

Yishai commented Nov 12, 2009

I agree. It is a strange requirement/limitation.

@aisrael
Copy link
Contributor

aisrael commented May 20, 2010

I'm voting this up, but only because I've gotten used to the DI/Spring (and other frameworks) way of 'peering' into the private internals of a class and perusing the members therein. On the other hand, I can see how sticking to public members avoids potential issues when using reflection when running under a security manager. One more reason for supporting non-public @Rules (and @Before/@After methods): we don't have to suppress Checkstyle's VisibilityModifier check.

@dlindner
Copy link

I agree, too. In the mailing list, there is already a working patch for this:
http://tech.groups.yahoo.com/group/junit/message/22445

@dsaff
Copy link
Member

dsaff commented Mar 2, 2011

Tests that grab private members reflectively can fail when run under security managers and runtimes that prevent such access, so we push test writers to make their tests most generally useful. Since the only "client" of a JUnit test class is the framework itself, I haven't seen a big loss in design from this requirement. Please bring this up on junit@yahoogroups.com if you strongly disagree, so we can hear from both sides. Thanks.

test-git-x-modules-app bot pushed a commit to vs/junit4 that referenced this issue Sep 13, 2022
Fix SL4J-EXT manifest, duplicate bundle name with SL4J-LOG4J
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants