0

I am new to Junit testing, would like to test a private method within a class.But it causing visibility problems.how can i test a private method or protected method using Junit.Or can i test a logic within a constructor with Junit??

rohithrkrk
  • 29
  • 1
  • 10
  • 4
    Possible duplicate of [How to test a class that has private methods, fields or inner classes?](http://stackoverflow.com/questions/34571/how-to-test-a-class-that-has-private-methods-fields-or-inner-classes) – Stefan Birkner Jan 22 '16 at 07:32

1 Answers1

-3

Simply do it like this:

private someMethod() {}

public someMethodVisibleToAll() {
     someMethod();
}

It's not a good idea to hide complex logic in private methods without any access to test it, try to make methods idempotent (without side effects).

In case of legacy code use Powermock, but first try to refactor to code above, if it's not possible than you Powermock as last emergency break.

Just notice: Protected methods are testbable if you use convention that JUnit test has same package name e.g

code src/main/java

package my.package.first

in JUnit folder src/main/test

package my.package.first

than all your protected methods are available to test

Update:

There should always be a way to test private methods indirectly through public methods or protected which uses or includes using of private methods which are cases for testing. If this isn't true and you are not dependent on legacy or third party code, than it's an alert that something is wrong with class design.

bodo
  • 827
  • 6
  • 19
  • 2
    This solution is poluting the public API. Putting `someMethod` directly to package private or protected visibility would be more conservative. – CoronA Jan 22 '16 at 06:51
  • How is it polluting public API? If the method doesn't have side effects? But yes use protected is more secure in case when method have side effects, but then it comes to question, is it designed safe way?. But that is other story I think. – bodo Jan 22 '16 at 07:14
  • @CoronA I think public API should by in most time interface with clearly choosing methods to expose to world, which should be changend only in rare cases. So if your class has public methods that are not part of interface and those methods are without side effects then I don't see reason to make them protected or private. – bodo Jan 22 '16 at 07:21
  • @Rohith Just a notice there should always be a way to test private methods indirectly through public methods or protected which uses or includes using of private methods which are cases for testing. If this isn't true and you are not dependent on legacy or third party code, than it's an alert that something is wrong with class design. – bodo Jan 22 '16 at 07:37
  • Your suggestion was to create a public method delegating to the private one. That extends the public api with a method that should never be used (unless in tests, otherwise the private method is not really private). I agree that real problems will only occur if the method has side effects. But Java is OO. It is designed be adaptable to changes and polymorphic overrides. Nobody can ensure that such a public method is later overridden with side effects. – CoronA Jan 22 '16 at 07:48
  • @CoronA Yes I agree, but than It's a programer problem. He should always need to know what he wants to achieve, in simply words that he knows what he is doing, private keyword won't stop him doing side effect or make a bad code, no matter he is using OOP, functional paradigma etc. – bodo Jan 22 '16 at 07:57
  • So basically just make every method public from the start...no thanks. There's a reason we can control the visibility of methods. I refuse to make a should-be-private method visibly public just to run unit tests against it. There's a better way, surely. – Josh M. Jun 28 '18 at 12:47
  • I have used java reflection API to call private method and it worked for my purpose.Thank you. – rohithrkrk Oct 22 '18 at 08:31