views:

193

answers:

7

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 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));
  }
 }
}

Edit:

solutions :

1.Not test private methods - Sometimes private method doing very compicated tasks that should be tested very well and we dont want that user will have access to this methods. Soo the solution is change private methods to protected.

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

3.Reflaction - If this make possible to call for private methods, its looks great solution http://www.artima.com/suiterunner/private3.html

( I should learn more to understand reflaction,I don't understand how reflactions not breaks all idea of public, private if we can to call to private methods from other class.)

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

+3  A: 

This question is already answered here.

fencliff
+1  A: 

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

foret
+1  A: 

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

Kendrick
+2  A: 

Look at this article about testing private methods with JUnit.

Romain Hippeau
This answer points to a good resource on how to test private methods, but make very sure you read the other answers which all pretty much say that with properly designed code you shouldn't need to (and give good reasons why)
Chris Knight
+9  A: 

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).
Sjoerd
+1 for a good explanation of why this is a design problem, and how to solve it.
Tomas Lycken
+1  A: 

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.

Visage
+2  A: 

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).

Kragen