How do I test a private function or a class that has private methods fields or inner classes

Question

How do I unit test  using xUnit  a class that has internal private methods  fields or nested classes  Or a function that is made private by having internal linkage  static in C C    or is in a private  anonymous  namespace   It seems bad to change the access modifier for a method or function just to be able to run a test

User · Answer

As others have said    don t test private methods directly  Here are a few thoughts    Keep all methods small and focused  easy to test  easy to find what is wrong  Use code coverage tools  I like Cobertura  oh happy day  looks like a new version is out     Run the code coverage on the unit tests  If you see that methods are not fully tested add to the tests to get the coverage up  Aim for 100  code coverage  but realize that you probably won t get it

User · Answer

If you want to test private methods of a legacy application where you can t change the code  one option for Java is jMockit  which will allow you to create mocks to an object even when they re private to the class

User · Answer

JML has a spec public comment annotation syntax that allows you to specify a method as public during tests   private     spec public     int methodName            This syntax is discussed at http   www eecs ucf edu  leavens JML jmlrefman jmlrefman 2 html SEC12  There also exists a program that translates JML specifications into JUnit tests  I m not sure how well that works or what its capabilities are  but it doesn t appear to be necessary since JML is a viable testing framework on its own

User · Answer

If you have a case where you really need to test a private method class etc   directly  you can use reflection as already mentioned in other answers  However if it comes to that  instead of dealing directly with reflection I d rather use util classes provided by your framework  For instance  for Java we have    ReflectionUtils  Spring framework ReflectionUtils JUnit   As per how to use them  you can find plenty of articles online  Here one that I particularly liked    Java Code Examples for org springframework util ReflectionUtils

User · Answer

What if your test classes are in the same package as the class that should be tested   But in a different directory of course  src  amp  classes for your source code  test src and test classes for your test classes  And let classes and test classes be in your classpath

User · Answer

Private methods are consumed by public ones  Otherwise  they re dead code  That s why you test the public method  asserting the expected results of the public method and thereby  the private methods it consumes   Testing private methods should be tested by debugging before running your unit tests on public methods   They may also be debugged using test-driven development  debugging your unit tests until all your assertions are met   I personally believe it is better to create classes using TDD  creating the public method stubs  then generating unit tests with all the assertions defined in advance  so the expected outcome of the method is determined before you code it  This way  you don t go down the wrong path of making the unit test assertions fit the results  Your class is then robust and meets requirements when all your unit tests pass

User · Answer

If using Spring  ReflectionTestUtils provides some handy tools that help out here with minimal effort  For example  to set up a mock on a private member without being forced to add an undesirable public setter   ReflectionTestUtils setField theClass   theUnsettableField   theMockObject

User · Answer

Another approach I have used is to change a private method to package private or protected then complement it with the  VisibleForTesting annotation of the Google Guava library   This will tell anybody using this method to take caution and not access it directly even in a package  Also a test class need not be in same package physically  but in the same package under the test folder   For example  if a method to be tested is in src main java mypackage MyClass java then your test call should be placed in src test java mypackage MyClassTest java  That way  you got access to the test method in your test class

User · Answer

I recently had this problem and wrote a little tool  called Picklock  that avoids the problems of explicitly using the Java reflection API  two examples   Calling methods  e g  private void method String s  - by Java reflection  Method method   targetClass getDeclaredMethod  method   String class   method setAccessible true   return method invoke targetObject   mystring      Calling methods  e g  private void method String s  - by Picklock  interface Accessible     void method String s          Accessible a   ObjectAccess unlock targetObject  features Accessible class   a method  mystring      Setting fields  e g  private BigInteger amount  - by Java reflection  Field field   targetClass getDeclaredField  amount    field setAccessible true   field set object  BigInteger valueOf 42      Setting fields  e g  private BigInteger amount  - by Picklock  interface Accessible     void setAmount BigInteger amount          Accessible a   ObjectAccess unlock targetObject  features Accessible class   a setAmount BigInteger valueOf 42

User · Answer

PowerMockito is made for this  Use maven dependency      lt dependency gt           lt groupId gt org powermock lt  groupId gt           lt artifactId gt powermock-core lt  artifactId gt           lt version gt 2 0 7 lt  version gt           lt scope gt test lt  scope gt       lt  dependency gt   Then you can do import org powermock reflect Whitebox      MyClass sut   new MyClass    SomeType rval   Whitebox invokeMethod sut   quot myPrivateMethod quot   params  moreParams

User · Answer

The following Reflection TestUtil could be used generically to test the private methods for their atomicity   import com google common base Preconditions   import org springframework test util ReflectionTestUtils           lt p gt     Invoker     lt  p gt         author     created Oct-10-2019     public class Invoker       private Object target      private String methodName      private Object   arguments       public  lt T gt  T invoke             try               Preconditions checkNotNull target   Target cannot be empty                Preconditions checkNotNull methodName   MethodName cannot be empty                if  null    arguments                    return ReflectionTestUtils invokeMethod target  methodName                 else                   return ReflectionTestUtils invokeMethod target  methodName  arguments                           catch  Exception e               throw e                       public Invoker withTarget Object target            this target   target          return this             public Invoker withMethod String methodName            this methodName   methodName          return this             public Invoker withArguments Object    args            this arguments   args          return this            Object privateMethodResponse   new Invoker      withTarget targetObject     withMethod PRIVATE METHOD NAME TO INVOKE     withArguments arg1  arg2  arg3     invoke    Assert assertNotNutll privateMethodResponse

User · Answer

I d like to contribute that of you are worried by not testing private methods as many of the posts suggest  consider that a code coverage tool will determine exactly how much of your code is tested and where it leaks  so it is quantifiably acceptable to do this   I am going to say something that needs to be said but many may not like to hear  Those of you contributing answers that direct the author of the question towards a  work around  are doing a massive disservice to the community  Testing is a major part of all engineering disciplines  you would not want to buy a car that is not properly tested  and tested in a meaningful way  so why would anyone want to buy or use software that is tested poorly  The reason people do this anyways is probably because the effects of badly tested software are felt way after the fact  and we don t usually associate them with bodily harm  This is a very dangerous perception which will be difficult to change  but it is our responsibility to deliver safe products regardless of what even management is bullying us to do  Think Equifax hack      We must strive to build an environment that encourages good software engineering practices  this does not mean ostracizing the weak lazy among us who do not take their craft seriously  but rather  to create a status quo of accountability and self reflection that would encourage everyone to pursue growth  both mentally and skillfully  I am still learning  and may have wrong perceptions opinions myself  but I do firmly believe that we need to hold ourselves accountable to good practices and shun irresponsible hacks or workarounds to problems

User · Answer

A private method is only to be accessed within the same class  So there is no way to test a    private    method of a target class from any test class  A way out is that you can perform unit testing manually or can change your method from    private    to    protected      And then a protected method can only be accessed within the same package where the class is defined  So  testing a protected method of a target class means we need to define your test class in the same package as the target class   If all the above does not suits your requirement  use the  reflection way to access the private method

User · Answer

My team and I are using Typemock  which has an API that allows you to fake non-public methods   Recently they added the ability to fake non-visible types and to use XUnit

User · Answer

When I have private methods in a class that are sufficiently complicated that I feel the need to test the private methods directly  that is a code smell  my class is too complicated     My usual approach to addressing such issues is to tease out a new class that contains the interesting bits   Often  this method and the fields it interacts with  and maybe another method or two can be extracted in to a new class     The new class exposes these methods as  public   so they re accessible for unit testing   The new and old classes are now both simpler than the original class  which is great for me  I need to keep things simple  or I get lost     Note that I m not suggesting that people create classes without using their brain  The point here is to use the forces of unit testing to help you find good new classes

User · Answer

Please see below for an example   The following import statement should be added   import org powermock reflect Whitebox    Now you can directly pass the object which has the private method  method name to be called  and additional parameters as below   Whitebox invokeMethod obj   privateMethod    param1

User · Answer

The best way to test a private method is via another public method  If this cannot be done  then one of the following conditions is true    The private method is dead code There is a design smell near the class that you are testing The method that you are trying to test should not be private

User · Answer

For C    since C  11  adding the test class as a friend works perfectly and does not break production encapsulation   Let s suppose that we have some class Foo with some private functions which really require testing  and some class FooTest that should have access to Foo s private members  Then we should write the following      prod h  some production code header     forward declaration is enough    we should not include testing headers into production code class FooTest   class Foo        that does not affect Foo s functionality      but now we have access to Foo s members from FooTest   friend FooTest  public    Foo    private    bool veryComplicatedPrivateFuncThatReallyRequiresTesting           test cpp  some test  include  lt prod h gt   class FooTest   public    void complicatedFisture         Foo foo      ASSERT TRUE foo veryComplicatedPrivateFuncThatReallyRequiresTesting            int main int   argc    char  argv        FooTest test    test complicatedFixture        and it really works

User · Answer

PowerMock Whitebox is the best option I have seen  but when I read its source code  it reads private fields with reflection  so I think I have my answer     test private internal states fields  with PowerMock  or just reflection without the overhead of introducing another independency for private methods  actually  the upvote for this question itself  and the huge number of comments and answers  shows that it is a very concurrent and controversial topic where no definite answer could be given to suit every circumstance  I understand that only contract should be tested  but we also have coverage to consider  Actually  I doubt that only testing contracts will 100  make a class immune to errors  Private methods are those who process data in the class where it is defined and thus does not interest other classes  so we cannot simply expose to make it testable  I will try not to test them  but when you have to  just go for it and forget all the answers here  You know better your situation and restrictions than any other one in the Internet  When you have control over your code  use that  With consideration  but without over-thinking       After some time  when I reconsider it  I still believe this is true  but I saw better approaches   First of all  Powermock Whitebox is still usable    And  Mockito Whitebox has been hidden after v2 the latest version I can find with Whitebox is testImplementation  org mockito mockito-core 1 10 19   and it has always been part of org mockito internal package  which is prone of breaking changes in the future see this post   So now I tend not to use it    In Gradle Maven projects  if you define private methods or fields  there is no other ways then reflection to get access to them  so the first part stays true  But  if you change the visibility to  package private   the tests following the same structure in test package will have access to them  That is also another important reason why we are encouraged to create the same hierarchy in main and test package  So  when you have control over production code as well as tests  delete that private access modifier may be the best option for you because relatively it does not cause huge impact  And  that makes testing as well as private method spying possible    Autowired private SomeService service     with a package private method  doSomething      Test void shouldReturnTrueDoSomething         assertThat doSomething input   is true       package private method testing     Test void shouldReturnTrueWhenServiceThrowsException         SomeService spy   Mockito spy service      spying real object     doThrow new AppException    when spy  doSomething input      spy package private method              When it comes to internal fields  in Spring you have ReflectionUtils setField      At last  sometimes we can bypass the problem itself  if there is a coverage requirement to meet  maybe you can move these private methods into an inner static class and ignore this class in Jacoco  I just found some way to ignore inner class in Jacoco gradle tasks  another question

User · Answer

A quick addition to  Cem Catikka s comment  when using ExpectedException   Keep in mind that your expected exception will be wrapped in an InvocationTargetException  so in order to get to your exception you will have to throw the cause of the InvocationTargetException you received  Something like  testing private method validateRequest   on BizService     Rule public ExpectedException thrown   ExpectedException none      Autowired required   true  private BizService svc     Test public void testValidateRequest   throws Exception        thrown expect BizException class       thrown expectMessage expectMessage        BizRequest request      Mock it  read from source - file  etc          validateRequest request      private void validateRequest BizRequest request  throws Exception       Method method   svc getClass   getDeclaredMethod  validateRequest   BizRequest class       method setAccessible true       try           method invoke svc  request             catch  InvocationTargetException e            throw   BizException e getCause

User · Answer

Hey use this utility class if you are on spring   ReflectionTestUtils invokeMethod new ClassName     privateMethodName

User · Answer

In your class  namespace my namespace        ifdef UNIT TEST         class test class       endif      class my class           public               ifdef UNIT TEST                 friend class test class               endif         private              void fun     cout  lt  lt   quot I am private quot   lt  lt  endl             In your unit test class   ifndef UNIT TEST      define UNIT TEST  endif   include  quot my class h quot   class my namespace  test class       public          void fun     my obj fun          private          my class my obj     void my unit test         test class test obj      test obj fun       here you accessed the private function

User · Answer

I tend not to test private methods   There lies madness   Personally  I believe you should only test your publicly exposed interfaces  and that includes protected and internal methods

User · Answer

Testing private methods breaks the encapsulation of your class because every time you change the internal implementation you break client code  in this case  the tests    So don t test private methods

User · Answer

As many above have suggested  a good way is to test them via your public interfaces   If you do this  it s a good idea to use a code coverage tool  like Emma  to see if your private methods are in fact being executed from your tests

User · Answer

In c     before including class header that has a private function that you want test it  Use this code    define private public  define protected public

User · Answer

In the Spring Framework you can test private methods using this method   ReflectionTestUtils invokeMethod     For example   ReflectionTestUtils invokeMethod TestClazz   createTest    input data

User · Answer

I have used reflection to do this for Java in the past  and in my opinion it was a big mistake   Strictly speaking  you should not be writing unit tests that directly test private methods  What you should be testing is the public contract that the class has with other objects  you should never directly test an object s internals  If another developer wants to make a small internal change to the class  which doesn t affect the classes public contract  he she then has to modify your reflection based test to ensure that it works  If you do this repeatedly throughout a project  unit tests then stop being a useful measurement of code health  and start to become a hindrance to development  and an annoyance to the development team   What I recommend doing instead is using a code coverage tool such as Cobertura  to ensure that the unit tests you write provide decent coverage of the code in private methods  That way  you indirectly test what the private methods are doing  and maintain a higher level of agility

User · Answer

You can turn off Java access restrictions for reflection so that private means nothing   The setAccessible true  call does that   The only restriction is that a ClassLoader may disallow you from doing that   See Subverting Java Access Protection for Unit Testing  Ross Burton  for a way to do this in Java

User · Answer

I would suggest you refactoring your code a little bit  When you have to start thinking about using reflection or other kind of stuff  for just testing your code  something is going wrong with your code   You mentioned different types of problems  Let s start with private fields  In case of private fields I would have added a new constructor and injected fields into that  Instead of this   public class ClassToTest        private final String first    first       private final List lt String gt  second   new ArrayList lt  gt                 I d have used this   public class ClassToTest        private final String first      private final List lt String gt  second       public ClassToTest             this  first   new ArrayList lt  gt                 public ClassToTest final String first  final List lt String gt  second            this first   first          this second   second                    This won t be a problem even with some legacy code  Old code will be using an empty constructor  and if you ask me  refactored code will look cleaner  and you ll be able to inject necessary values in test without reflection   Now about private methods  In my personal experience when you have to stub a private method for testing  then that method has nothing to do in that class  A common pattern  in that case  would be to wrap it within an interface  like Callable and then you pass in that interface also in the constructor  with that multiple constructor trick    public ClassToTest         this          public ClassToTest final Callable lt T gt  privateMethodLogic        this privateMethodLogic   privateMethodLogic      Mostly all that I wrote looks like it s a dependency injection pattern  In my personal experience it s really useful while testing  and I think that this kind of code is cleaner and will be easier to maintain  I d say the same about nested classes  If a nested class contains heavy logic it would be better if you d moved it as a package private class and have injected it into a class needing it   There are also several other design patterns which I have used while refactoring and maintaining legacy code  but it all depends on cases of your code to test  Using reflection mostly is not a problem  but when you have an enterprise application which is heavily tested and tests are run before every deployment everything gets really slow  it s just annoying and I don t like that kind of stuff    There is also setter injection  but I wouldn t recommended using it  I d better stick with a constructor and initialize everything when it s really necessary  leaving the possibility for injecting necessary dependencies

User · Answer

Just two examples of where I would want to test a private method    Decryption routines - I would not want to make them visible to anyone to see just for the sake of testing  else anyone can use them to decrypt  But they are intrinsic to the code  complicated  and need to always work  the obvious exception is reflection which can be used to view even private methods in most cases  when SecurityManager is not configured to prevent this   Creating an SDK for community consumption  Here public takes on a wholly different meaning  since this is code that the whole world may see  not just internal to my application   I put code into private methods if I don t want the SDK users to see it - I don t see this as code smell  merely as how SDK programming works  But of course I still need to test my private methods  and they are where the functionality of my SDK actually lives    I understand the idea of only testing the  contract   But I don t see one can advocate actually not testing code - your mileage may vary   So my tradeoff involves complicating the JUnits with reflection  rather than compromising my security  amp  SDK

User · Answer

Having tried Cem Catikkas  solution using reflection for Java  I d have to say his was a more elegant solution than I have described here  However  if you re looking for an alternative to using reflection  and have access to the source you re testing  this will still be an option   There is possible merit in testing private methods of a class  particularly with test-driven development  where you would like to design small tests before you write any code   Creating a test with access to private members and methods can test areas of code which are difficult to target specifically with access only to public methods  If a public method has several steps involved  it can consist of several private methods  which can then be tested individually   Advantages    Can test to a finer granularity   Disadvantages    Test code must reside in the same file as source code  which can be more difficult to maintain Similarly with  class output files  they must remain within the same package as declared in source code   However  if continuous testing requires this method  it may be a signal that the private methods should be extracted  which could be tested in the traditional  public way   Here is a convoluted example of how this would work      Import statements and package declarations  public class ClassToTest       private int decrement int toDecrement            toDecrement--          return toDecrement                Constructor and the rest of the class      public static class StaticInnerTest extends TestCase               public StaticInnerTest                super                       public void testDecrement                int number   10              ClassToTest toTest  new ClassToTest                int decremented   toTest decrement number               assertEquals 9  decremented                      public static void main String   args                junit textui TestRunner run StaticInnerTest class                       The inner class would be compiled to ClassToTest StaticInnerTest   See also  Java Tip 106  Static inner classes for fun and profit

User · Answer

For Java I d use reflection  since I don t like the idea of changing the access to a package on the declared method just for the sake of testing  However  I usually just test the public methods which should also ensure the private methods are working correctly      you can t use reflection to get private methods from outside the owner class  the private modifier affects reflection also   This is not true  You most certainly can  as mentioned in Cem Catikkas s answer

User · Answer

The private methods are called by a public method  so the inputs to your public methods should also test private methods that are called by those public methods  When a public method fails  then that could be a failure in the private method

User · Answer

In C  you could have used System Reflection  though in Java I don t know  Though I feel the urge to answer this anyway since if you  feel you need to unit test private methods  my guess is that there is something else which is wrong     I would seriously consider looking at my architecture again with fresh eyes

User · Answer

I am not sure whether this is a good technique  but I developed the following pattern to unit test private methods   I don t modify the visibility of the method that I want to test and add an additional method  Instead I am adding an additional public method for every private method I want to test  I call this additional method Test-Port and denote them with the prefix t   This Test-Port method then simply accesses the according private method   Additionally I add a boolean flag to the Test-Port method to decide whether I grant access to the private method through the Test-Port method from outside  This flag is then set globally in a static class where I place e g  other global settings for the application  So I can switch the access to the private methods on and off in one place e g  in the corresponding unit test

User · Answer

Generally a unit test is intended to exercise the public interface of a class or unit  Therefore  private methods are implementation detail that you would not expect to test explicitly

User · Answer

Update       Some 10 years later perhaps the best way to test a private method  or any inaccessible member  is via  Jailbreak from the Manifold framework    Jailbreak Foo foo   new Foo       Direct   type-safe  access to  all  foo s members foo privateMethod x  y  z   foo privateField   value        This way your code remains type-safe and readable   No design compromises  no overexposing methods and fields for the sake of tests    If you have somewhat of a legacy Java application  and you re not allowed to change the visibility of your methods  the best way to test private methods is to use reflection    Internally we re using helpers to get set private and private static variables as well as invoke private and private static methods  The following patterns will let you do pretty much anything related to the private methods and fields  Of course  you can t change private static final variables through reflection   Method method   TargetClass getDeclaredMethod methodName  argClasses   method setAccessible true   return method invoke targetObject  argObjects     And for fields   Field field   TargetClass getDeclaredField fieldName   field setAccessible true   field set object  value          Notes    1  TargetClass getDeclaredMethod methodName  argClasses  lets you look into private methods  The same thing applies for   getDeclaredField    2  The setAccessible true  is required to play around with privates

User · Answer

Groovy has a bug feature  through which you can invoke private methods as if they were public   So if you re able to use Groovy in your project  it s an option you can use in lieu of reflection   Check out this page for an example

User · Answer

Here is my generic function to test private fields   protected  lt F gt  F getPrivateField String fieldName  Object obj      throws NoSuchFieldException  IllegalAccessException       Field field           obj getClass   getDeclaredField fieldName        field setAccessible true       return  F field get obj

User · Answer

Today  I pushed a Java library to help testing private methods and fields  It has been designed with Android in mind  but it can really be used for any Java project   If you got some code with private methods or fields or constructors  you can use BoundBox  It does exactly what you are looking for  Here below is an example of a test that accesses two private fields of an Android activity to test it    UiThreadTest public void testCompute             Given     boundBoxOfMainActivity   new BoundBoxOfMainActivity getActivity             When     boundBoxOfMainActivity boundBox getButtonMain   performClick            Then     assertEquals  42   boundBoxOfMainActivity boundBox getTextViewMain   getText         BoundBox makes it easy to test private protected fields  methods and constructors  You can even access stuff that is hidden by inheritance  Indeed  BoundBox breaks encapsulation  It will give you access to all that through reflection  BUT everything is checked at compile time   It is ideal for testing some legacy code  Use it carefully      https   github com stephanenicolas boundbox

User · Answer

Detail my sample with lombok as below  private field  private method  public static void main String   args  throws NoSuchFieldException  SecurityException  IllegalArgumentException  IllegalAccessException  NoSuchMethodException  InvocationTargetException       Student student   new Student         Field privateFieldName   Student class getDeclaredField  quot name quot        privateFieldName setAccessible true       privateFieldName set student   quot Naruto quot         Field privateFieldAge   Student class getDeclaredField  quot age quot        privateFieldAge setAccessible true       privateFieldAge set student   quot 28 quot         System out println student toString          Method privateMethodGetInfo   Student class getDeclaredMethod  quot getInfo quot   String class  String class       privateMethodGetInfo setAccessible true       System out println privateMethodGetInfo invoke student   quot Sasuke quot    quot 29 quot          Setter  Getter  ToString class Student     private String name    private String age     private String getInfo String name  String age        return name    quot - quot    age

User · Answer

I only test the public interface  but I have been known to make specific private methods protected so I can either mock them out entirely  or add in additional steps specific for unit testing purposes  A general case is to hook in flags I can set from the unit test to make certain methods intentionally cause an exception to be able to test fault paths  the exception triggering code is only in the test path in an overridden implementation of the protected method   I minimize the need for this though and I always document the precise reasons to avoid confusion

User · Answer

You can use PowerMockito to set return values for private fields and private methods that are called used in the private method you want to test   Eg  Setting return value for private method   MyClient classUnderTest   PowerMockito spy new MyClient        Set expected return value PowerMockito doReturn 20  when classUnderTest   myPrivateMethod   anyString    anyInt       This is very important otherwise it will not work classUnderTest myPrivateMethod        Setting private field value as someValue  Whitebox setInternalState classUnderTest   privateField   someValue     Then finally you can validate your private method under test is returning correct value based on set values above by   String msg   Whitebox invokeMethod obj   privateMethodToBeTested    param1    Assert assertEquals privateMsg  msg     Or   If classUnderTest private method does not return value but it set another private field then you can get that private field value to see if it was set correctly     To get value of private field MyClass obj   Whitebox getInternalState classUnderTest   foo    assertThat obj  is notNull MyClass class        or test value

User · Answer

You can create a special public method to proxy the private method to test  The  TestOnly annotation is out of the box available when using IntelliJ  The downside is is that if somebody want to to use the private method in a public context  he can do it  But he will be warned by the annotation and the method name  On IntelliJ a warning will appear when doing it   import org jetbrains annotations TestOnly  class MyClass        private void aPrivateMethod            TestOnly     public void aPrivateMethodForTest             aPrivateMethod

User · Answer

There is another approach to test your private methods  If you  enable assertion  in run configurations then you can unit test your method inside method itself  For example   assert   Ercan  equals person1 name    assert  Person count    2

User · Answer

Best and proper legal way to test Java private method from test framework is  VisibleForTesting annotation over the method so same method will be visible for test framework as like public method

User · Answer

The answer from JUnit org FAQ page      But if you must         If you are using JDK 1 3 or higher  you can use reflection to subvert   the access control mechanism with the aid of the PrivilegedAccessor    For details on how to use it  read this article       If you are using JDK 1 6 or higher and you annotate your tests with    Test  you can use Dp4j to inject reflection in your test methods  For   details on how to use it  see this test script    P S  I m the main contributor to Dp4j  ask me if you need help

User · Answer

If you are only using Mockito   You can consider the private method as a part of public method being tested  You can make sure you cover all the cases in private method when testing public method   Suppose you are a mockito only user You are not allowed or don t want to use Powermock or reflection or any such tools  and you dont want to change the existing code or libraries being tested  this might be the best way    The only thing you need to handle if you choose this way is the variables user defined objects  declared locally within private methods   If the private method depends on locally declared variable objects and their methods  make sure you declare those user defined objects globally as private object instead of locally declared objects  You can instantiate these objects locally     This allows you to mock these objects and inject them back to testing object  You can also mock using when then  their methods    This will allow you test private method without errors when testing the public method   Advantages 1  code coverage 2  Able to test the complete private method   Disadvantages 1  Scope of the Object - If you don t want the object to be exposed to other methods within same class  this might not be your way  2  You might end up testing the private method multiple times when invoked at different public methods and or in same method multiple times

User · Answer

From this article  Testing Private Methods with JUnit and SuiteRunner  Bill Venners   you basically have 4 options         Don t test private methods    Give the methods package access    Use a nested test class    Use reflection

User · Answer

If you re trying to test existing code that you re reluctant or unable to change  reflection is a good choice   If the class s design is still flexible  and you ve got a complicated private method that you d like to test separately  I suggest you pull it out into a separate class and test that class separately  This doesn t have to change the public interface of the original class  it can internally create an instance of the helper class and call the helper method   If you want to test difficult error conditions coming from the helper method  you can go a step further  Extract an interface from the helper class  add a public getter and setter to the original class to inject the helper class  used through its interface   and then inject a mock version of the helper class into the original class to test how the original class responds to exceptions from the helper  This approach is also helpful if you want to test the original class without also testing the helper class

User · Answer

Android has  VisibleForTesting annotation from android support annotation package      The  VisibleForTesting annotation indicates that an annotated method is more visible than normally necessary to make the method testable  This annotation has an optional otherwise argument that lets you designate what the visibility of the method should have been if not for the need to make it visible for testing  Lint uses the otherwise argument to enforce the intended visibility    On the practice it means that you should make a method open for testing and the  VisibleForTesting annotation will show a warning   For example  package com mypackage   public class ClassA         VisibleForTesting otherwise   VisibleForTesting PRIVATE      static void myMethod                And when you call ClassA myMethod   within the same package com mypackage  you will see the warning

User · Answer

First  I ll throw this question out  Why do your private members need isolated testing  Are they that complex  providing such complicated behaviors as to require testing apart from the public surface  It s unit testing  not  line-of-code  testing  Don t sweat the small stuff   If they are that big  big enough that these private members are each a  unit  large in complexity -- consider refactoring such private members out of this class   If refactoring is inappropriate or infeasible  can you use the strategy pattern to replace access to these private member functions   member classes when under unit test  Under unit test  the strategy would provide added validation  but in release builds it would be simple passthrough

User · Answer

If you re using JUnit  have a look at junit-addons  It has the ability to ignore the Java security model and access private methods and attributes

User · Answer

To test legacy code with large and quirky classes  it is often very helpful to be able to test the one private  or public  method I m writing right now   I use the junitx util PrivateAccessor-package for Java   Lots of helpful one-liners for accessing private methods and private fields   import junitx util PrivateAccessor   PrivateAccessor setField myObjectReference   myCrucialButHardToReachPrivateField   myNewValue   PrivateAccessor invoke myObjectReference   privateMethodName   java lang Class   parameterTypes  java lang Object   args

[java] How do I test a private function or a class that has private methods, fields or inner classes?

Examples related to java

Examples related to unit-testing

Examples related to tdd