Ccna final exam - java, php, javascript, ios, cshap all in one. This is a collaboratively edited question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
Friday, May 25, 2012
What"s the proper way to test a class with private methods using JUnit?
How do I use JUnit to test a class that has internal private methods? It seems bad to change the access modifier for a method just to be able to run a test.
If you have somewhat of a legacy application and you're not allowed to change the visibility of your methods, 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.
Field field = targetClass.getDeclaredField(fieldName); field.setAccessible(true); field.set(object, value);
Notes: * targetClass.getDeclaredMethod(methodName, argClasses) lets you look into private methods. Same thing applies for getDeclaredField. * The setAccessible(true) is required to play around with privates.
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
When I have private methods in a class that is 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 it 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 anyone create classes without using their brain! The point here is to use the forces of unit testing to help you find good new classes.
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.
Generally a unit test is intended to exercise the public interface of a class or unit, private methods therefore are implementation detail that you would not expect to test explicitly.
EDIT: Having tried Cem Catikkas' solution using reflection, 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 rest of 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); }
} }
Inner class would be compiled to ClassToTest$StaticInnerTest.
See also: http://www.javaworld.com/javaworld/javatips/jw-javatip106.html
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.
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 this one (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.
Since you're using JUnit, have you looked at junit-addons? It has the ability to ignore the java security model and access private methods and attributes.
You should definately look into PowerMock, it just recently hit 1.0!
"PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more."
Testing Private Methods breaks the encapsulation of your class beacuse every time you change the internal implementation you break client code (in this case the tests). So don't test private methods.
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. Lots of helpful one-liners for accessing private methods and private fields.
If you want to test private methods of a legacy application where you can't change the code, one option is jMockit, which will allow you to create mocks to an object even when they're private to the class.
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 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 pass-thru.
I have used Reflection to do this 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 Objects internals. If another developer wants to make a small internal change to the class, which doesn't affect the classes public contract, he 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.
Just two examples of where I would want to test a private method:
Decryption routines - I would not want to make them public 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. 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 app). 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 - ymmv.
So my tradeoff involves complicating the JUnits with reflection, rather than compromising my security & SDK.
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).
I'd use Reflection, since I don't like the idea of changing the access to package on the declared method just for the sake of testing. However, I usually just test the public methods which should also ensure the the private methods are working correctly.
Edit:
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 this 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....
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 & classes for your source code, test/src and test/classes for your test classes. And let be classes and test/classes be in your classpath.
You can turn off 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.
Here is a link to an article on doing this in Java
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.
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 boolian 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.
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.
If you have somewhat of a legacy application and you're not allowed to change the visibility of your methods, 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.
ReplyDeleteMethod 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:
* targetClass.getDeclaredMethod(methodName, argClasses) lets you look into private methods. Same thing applies for getDeclaredField.
* The setAccessible(true) is required to play around with privates.
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:
ReplyDeleteThe 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
When I have private methods in a class that is sufficiently complicated that I feel the need to test the private methods directly, that is a code smell: my class is too complicated.
ReplyDeleteMy usual approach to addressing it 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 anyone create classes without using their brain! The point here is to use the forces of unit testing to help you find good new classes.
From this link, you basically have 4 options:
ReplyDeleteDon't test private methods.
Give the methods package access.
Use a nested test class.
Use reflection.
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.
ReplyDeleteGenerally a unit test is intended to exercise the public interface of a class or unit, private methods therefore are implementation detail that you would not expect to test explicitly.
ReplyDeleteEDIT: Having tried Cem Catikkas' solution using reflection, 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.
ReplyDeleteThere 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 rest of 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);
}
}
}
Inner class would be compiled to ClassToTest$StaticInnerTest.
See also:
http://www.javaworld.com/javaworld/javatips/jw-javatip106.html
If you're trying to test existing code that you're reluctant or unable to change, reflection is a good choice.
ReplyDeleteIf 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.
As others have said... don't test private methods directly. Here are a few thoughts:
ReplyDeletekeep all methods small and focused (easy to test, easy to find what is wrong)
use code coverage tools, I like this one (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.
Since you're using JUnit, have you looked at junit-addons? It has the ability to ignore the java security model and access private methods and attributes.
ReplyDeleteYou should definately look into PowerMock, it just recently hit 1.0!
ReplyDelete"PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more."
Testing Private Methods breaks the encapsulation of your class beacuse every time you change the internal implementation you break client code (in this case the tests).
ReplyDeleteSo don't test private methods.
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.
ReplyDeleteI use the junitx.util.PrivateAccessor-package. 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);
Hope that was helpful :)
If you want to test private methods of a legacy application where you can't change the code, one option is jMockit, which will allow you to create mocks to an object even when they're private to the class.
ReplyDeleteAs many above have suggested, a good way is to test them via your public interfaces.
ReplyDeleteIf 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.
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 public surface? It's unit testing, not 'line-of-code' testing. Don't sweat the small stuff.
ReplyDeleteIf 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 pass-thru.
I have used Reflection to do this in the past, and in my opinion it was a big mistake.
ReplyDeleteStrictly 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 Objects internals. If another developer wants to make a small internal change to the class, which doesn't affect the classes public contract, he 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.
Just two examples of where I would want to test a private method:
ReplyDeleteDecryption routines - I would not
want to make them public 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.
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 app). 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 - ymmv.
So my tradeoff involves complicating the JUnits with reflection, rather than compromising my security & SDK.
check this article : Testing Private Methods with JUnit and SuiteRunner
ReplyDeleteTo answer your question, I've developed dp4j; All you need is add dp4j.jar to your classpath (see instructions on website for eclipse).
ReplyDeleteNB: it's the first release, patches are welcome (there are known limitations to be addressed in next releases)!
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).
ReplyDeleteI'd use Reflection, since I don't like the idea of changing the access to package on the declared method just for the sake of testing. However, I usually just test the public methods which should also ensure the the private methods are working correctly.
ReplyDeleteEdit:
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 this 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...
ReplyDeleteI would seriously consider looking at my architecture again with fresh eyes....
What if your test classes are in the same package as the class that should be tested ?
ReplyDeleteBut in a different directory of course, src & classes for your source code, test/src and test/classes for your test classes. And let be classes and test/classes be in your classpath.
@Juan Manuel
ReplyDeleteYou can turn off 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.
Here is a link to an article on doing this in Java
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.
ReplyDeleteI minimize the need for this though and I always document the precise reasons to avoid confusion.
I am not sure whether this is a good technique but I developed the following pattern to unit test private methods:
ReplyDeleteI 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 boolian 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.
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.
ReplyDelete