Drop the need for rules, setup and test methods to be public

[odrotbohm]

As JUnit is interacting with a test class by reflection anyway, there's absolutely no need to insist on @Rule fields to be declared as public. Neither that's the case for setup methods or test methods in general.

A framework interacting with the developer's types by reflection shouldn't impose visibility rules to standard type components like fields or methods unless absolutely necessary. Right now I find myself having to add public virtually everywhere with the only effect of losing control of visibilities in my code.

[snicoll]

👍

[Tibor17]

+1

[kcooney]

I might be misremembering some details, but I believe the reason why it was decided that the methods need to be public is that JUnit needs to run tests in many environments, including ones with a SecurityManager installed that doesn't allow you to use reflection to call non-public methods. It's not uncommon for tests to be run from multiple environments (an IDE, a continuous build system, a command line build tool) and if some of those environments have a SecurityManager installed and some don't, the tests would all fail on some of the environments. Even if some projects don't use security managers in any of their environments, people often learn JUnit by reading other peoples' tests, and having even simple tests work in some environments but not others would be confusing to those users.

[odrotbohm]

I'd argue that if you're using SecurityManagers, you're aware of that. Also, it's not that the tests would arbitrarily fail. If the method can't be invoked due to a SecurityManager in place, you get a pretty telling exception. JUnit could even detect that scenario and log a warning or throw an exception. If you need that, make your code public.

However, I still think the rest of the world would benefit from JUnit not constantly barking at you to make every rule field and test method public and by this basically force you to publicize all your code.

Basically: require things if necessary but leave the control and decision to developer as long as possible.

[kcooney]

While we appreciate the feedback, keep in mind that this subject has been dabated multiple times on the mailing lists, on bugs, and on pull requests. All of the arguments raised here have been raised before. I am just trying to provide a summary of the previous discussions.

[odrotbohm]

I wasn't aware of that. I just tried to be a good citizen and not only bitch about what bothers me on Twitter, but open a ticket as I see room for improvement ;).

[kcooney]

Here are a few threads I found

#31 #106 #911 #835 #737

There's probably more; many threads mention "public" somewhere, so I searched for some words that I remember coming up in conversations.

[StefanPenndorf]

@kcooney

Each of the tickets mentioned was closed without any debate using the security manager argument.

I've never come across a project or situation where a security manager was in place during test / build / test execution. Maybe we should ask on the mailing list if there is really some one affected by such a change? Never read that some one was supporting the security manager thesis.

Even if you allow private members there is nothing that would break old code or restricted projects.

Additionally I would argue if a security manager is required / in place for build environments developer machines should be setup to use a security manager as well - if they don't: who prevents developers from committing code to production that doesn't run with a security manager?

[kcooney]

Again, those were only the threads that I could easily find on github. I remember there being other discussions, but searching for "public" on github found too many threads.

Please feel free to start a thread on junit@yahoogroups.com

Although for production code, I care very much about visibility, requiring public access for test methods and fields has never bothered me. I'd love to hear (on the mailing list) arguments for why the requirement for public fields and methods is a problem for other people.

[rschmitt]

This feature request isn't about solving a problem so much as enhancing the experience of typing in test code. There are much more general routes to enhancing programmer convenience and productivity. You can create a live template (or whatever the Eclipse equivalent is) that will type everything for you; not just the public keyword, but the void keyword, the @Test annotation, the import statement for the annotation, the throws Exception clause, and the braces for the test method.

[junit-builds]

JUnit 4 is now in maintenance mode.

At this point, only critical bugs and security issues will be fixed.

The team has therefore decided to close this issue.