2010-07-21 23 views
16

Duplicar posible: What’s the best way of unit testing private methods?¿Cómo debo probar los métodos privados en Java?

yo soy un programador principiante, y no sé cómo escribir una aplicación que estar bien estructurado para las pruebas unitarias. Quiero escribir aplicaciones con la capacidad de agregar luego pruebas efectivas de unidades.

El problema es con los métodos private; no pueden probarse 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 mejor solución?

mi solución (splitLetters privadas => splitLetters protegidas) sería el siguiente: Clase

Fuente: Clase de

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

prueba:

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

Soluciones:

  1. No probando métodos privados - A veces un método privado está haciendo tareas muy complicadas que deben ser probadas muy bien, y no queremos que el usuario tenga acceso a este método. Pronto la solución está cambiando los métodos privados a protegidos.

  2. manera clase anidada para probar - problemático porque QA hacer cambios en el código fuente

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

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

+8

Muchos argumentarían que los métodos privados no necesitan ser probados, solo interfaces públicas. – David

+1

Duplicado de http://stackoverflow.com/questions/34571/whats-the-best-way-of-unit-testing-private-methods – onof

+0

Esta pregunta ya está respondida [aquí] (http://stackoverflow.com/ preguntas/34571/whats-the-best-way-de-unit-testing-private-methods). – jevakallio

Respuesta

0

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

2

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

25

No debería necesitar probar métodos privados.

  • Un método privado es específicamente parte de la implementación. No debe 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 mover 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 sea un paquete privado (el modificador de acceso predeterminado).
+2

+1 para una buena explicación de por qué esto es un problema de diseño y cómo resolverlo. –

3

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

3

Mi opinión personal es que se debe (cuando sea posible), sólo el comportamiento de prueba que se expone al usuario final de ese pedazo de funcionalidad, y por lo tanto que no se debe probar métodos privados:

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

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

Por supuesto, usted puede optar por subdividir los proyectos grandes en trozos más pequeños de la funcionalidad, en cuyo caso se puede optar por unidad de probar las interfaces entre las interfaces (por ejemplo, puede elegir a la unidad a prueba su capa de acceso a datos , a pesar de que la implementación de DAL no afecta directamente al usuario final).

Cuestiones relacionadas