example - ¿Cómo debo probar métodos privados en Java?

junit java

Question

Posible duplicado: ¿Cuál es la mejor manera de probar por unidad los métodos privados?

Soy un programador principiante, y no sé cómo escribir una aplicación que esté bien estructurada para pruebas de unidad. Quiero escribir aplicaciones con la capacidad de agregar luego pruebas unitarias efectivas.

El problema es con private métodos private : no pueden realizar pruebas fuera de sus clases.

¿Debo resolver este problema cambiando todos los métodos que son private a protected , y dejar que la clase de prueba extienda la clase de origen? ¿O hay una solución mejor?

Mi solución (splitLetters privados => splitLetters protegidos) funcionaría así:

Clase de fuente:

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

Clase de prueba

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

Soluciones:

1. No probar métodos privados : a veces un método privado está realizando tareas muy complicadas que deben probarse muy bien, y no queremos que el usuario tenga acceso a estos métodos. Pronto la solución está cambiando métodos privados a protegidos.

2. Clase anidada de prueba : problemática porque el control de calidad realiza cambios en el código fuente

3. Reflexión : si esto hace posible llamar métodos privados, parece una gran solución http://www.artima.com/suiterunner/private3.html (debería aprender más para comprender la reflexión. No entiendo cómo lo hacen las reflexiones. no rompa toda la idea de tener métodos públicos y privados si podemos llamar a métodos privados de otra clase.)

4. No definir métodos privados (como lo mostré en mi solución) - problemático porque a veces tenemos que definir un método privado.

Answer 1

En mi opinión, los métodos privados no deben ser probados. Las pruebas son para interfaces (en el sentido amplio de esta palabra).

Answer 2

Mi opinión personal es que usted debería (siempre que sea posible) solo probar el comportamiento que está expuesto al usuario final de esa pieza de funcionalidad y, por lo tanto, que no debe probar métodos privados:

1. La prueba no prueba nada, excepto para demostrar que una parte de la funcionalidad interna está "funcionando" de acuerdo con algo que no tiene sentido para las personas que utilizan su software.

2. Si cambia / reformula su implementación interna, puede encontrar que las pruebas unitarias comienzan a fallar cuando, de hecho, la funcionalidad externa expuesta no ha cambiado en absoluto.

Por supuesto, puede elegir subdividir los proyectos grandes en partes más pequeñas de funcionalidad, en cuyo caso puede elegir probar las interfaces entre las interfaces (por ejemplo, puede elegir probar su capa de acceso a los datos, a pesar del hecho de que el DAL la implementación no afecta directamente al usuario final).

Answer 3

No deberías necesitar probar los métodos privados. Cuando prueba sus métodos públicos, en teoría, también debe probar sus métodos privados.

Answer 4

No deberías necesitar probar métodos privados.

• Un método privado es específicamente parte de la implementación. No debes probar la implementación, sino la funcionalidad. Si prueba la funcionalidad que expone una clase, puede cambiar la implementación mientras depende de la prueba de la unidad.
• Si siente la necesidad de probar un método privado, esta es una buena señal de que debe pasar el método privado a otra clase y hacer público el método. Al hacer esto, obtienes clases más pequeñas y puedes probar los métodos fácilmente. Si no desea exponer esta nueva clase, puede hacer que el paquete sea privado (el modificador de acceso predeterminado).

Answer 5

Probar métodos privados implica probar la implementación, en lugar de la funcionalidad. Piense detenidamente sobre por qué quiere probar métodos privados y es posible que no necesite probarlos en absoluto.