I have always a confusion about the Methods in Junit. If someone is asking whether can I make a test method Private/Protected in Junit, So is he talking about the Method which should start with test or any other method like setup() , teardown() in Junit. What is the return type of Junit Method. So I have always seen the return type use to be Void so can we change the return type? Now sometimes the question will come like can I test a Private method Using Junit. So as much I know Junit by default call the method which will start with test and it should be Public then only It will be able to call outside of the class using Junit. So if I declared a test Method as private how Junit will call it or test it outside of the class.

javaunit-testingjunit

user1973591

Reputation:

Junit Test Method

I have always a confusion about the Methods in Junit.

If someone is asking whether can I make a test method Private/Protected in Junit, So is he talking about the Method which should start with test or any other method like setup() , teardown() in Junit.
What is the return type of Junit Method. So I have always seen the return type use to be Void so can we change the return type?
Now sometimes the question will come like can I test a Private method Using Junit. So as much I know Junit by default call the method which will start with test and it should be Public then only It will be able to call outside of the class using Junit. So if I declared a test Method as private how Junit will call it or test it outside of the class.

Upvotes: 1

Answers (3)

Bob Dalgleish

Reputation: 8227

For testing private methods, I recommend making them protected or package protected. Then you can create a subclass that overrides the method and test it.

I have seen many posts stating flatly that you MUST not test private methods. I cannot imagine less useful straitjacketing. If you are trying to refactor your code, you are obligated to yourself and everyone around you to create a set of tests that ensure that the functionality is preserved before you even start changing the code. With regression problems properly fenced in, you can then start refactoring/retesting/refactoring.

Similarly, internal methods often are the places where fault recognition or recovery are done. Testing of those methods requires that proper firewalling of data is performed and that "impossible" situations are recognized. Recovery operations should also be checked to see that they handle "impossible" situations as well.

Using reflection to test private methods is a last resort, but it may be necessary if you cannot change the class under test or if you have orders from management. The "bad practice" is that you are violating encapsulation. However, encapsulation is only of concern to blackbox testing; the process of whitebox testing involves finding out if ALL of your code works, not just the visible stuff.

Upvotes: -1

Paul Whelan

Reputation: 16809

1) Your test methods should be public.

2) return type is always void.

3) You don't test private methods you test the public methods in your class, which will in turn presumably call the logic within your private methods. You should try and cover all the branches of code within these private methods too.

Upvotes: 1

Evgeniy Dorofeev

Reputation: 135992

From org.junit.Test annotation docs

The Test annotation tells JUnit that the public void method to which it is attached can be run as a test case

Upvotes: 0

Junit Test Method

Answers (3)

Related Questions