How should I test private methods in Java? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate: What’s the best way of unit testing private methods?

I am a beginner programmer, and I don't know how to write an application that will be well structured for unit testing. I want to write applications with the ability to afterwards add effective unit tests.

The problem is with private methods - they can't be testing with outside of their classes.

Should开发者_Go百科 I solve this problem by changing all methods that are private to protected, and let the test class extend source class? Or is there a better solution?

My solution (private splitLetters => protected splitLetters) would work like this:

Source class:

class MyClass{
  protected splitLetters(int num){
    return num+2;
  }
}

Test class:

class Test_MyClass extend MyClass{
  public splitLettersTest(){
  for(int i=0;i<100;i++){
    System.println(parent.splitLetters(i));
  }
 }
}

Solutions:

1. Not testing private methods - Sometimes a private method is doing very complicated tasks that should be tested very well, and we don't want that user will have access to this methods. Soon the solution is changing private methods to protected.

2. Nested class way to test - problematic because QA make changes in source code

3. Reflection - If this makes it possible to call private methods, it looks like a great solution http://www.artima.com/suiterunner/private3.html (I should learn more to understand reflection. I don't understand how reflections do not break all the idea of having public and private methods if we can call private methods from another class.)

4. Not define private methods (as I showed in my solution) - problematic because sometimes we have to define a private method.

---

You should not need to test private methods.

• A private method is specifically part of the implementation. You should not test the implemenation, but the functionality. If you test the functionality a class exposes, you can change the implementation while depending on the unit test.
• If you feel the need to test a private method, this is a good sign that you should move the private method to another class and make the method public. By doing this, you get smaller classes and you can test the methods easily. If you do not want to expose this new class, you can make it package-private (the default access modifier).

---

Testing private methods implies testing implementation, rather than functionality. Think very carefully about why you want to test private methods and you may find you dont need to test them at all.

---

My personal view is that you should (wherever possible) only test behaviour that is exposed to the end user of that piece of functionality, and therefore that you should not test private methods:

1. The test doesn't prove anything except to show that a piece of internal functionality is "working" according to something that makes no sense to the people actually using your software.

2. If you change / re-factor your internal implementation you could find that your unit tests start failing when in fact the external functionality exposed has not changed at all!

Of course you may choose to subdivide large projects up into smaller chunks of functionality, in which case you might choose to unit test the interfaces between the interfaces (for example you might choose to unit test your data access layer, despite the fact that the DAL implementation doesn't directly impact the end user).

---

You shouldn't need to test the private methods. When you test your public methods that should, in theory, also test your private methods.

---

In my opinion, private methods should not be tested. Tests are for interfaces (in the broad meaning of this word).