2010-05-06 26 views
6

Realicé la refactorización "Replace Method with Method Object" descrita por Beck.¿Cómo puedo probar los métodos en un objeto de método?

Ahora, tengo una clase con un método "run()" y un grupo de funciones miembro que descomponen el cálculo en unidades más pequeñas. ¿Cómo pruebo esas funciones miembro?

Mi primera idea es que mis pruebas unitarias sean básicamente copias del método "run()" (con diferentes inicializaciones), pero con aserciones entre cada llamada a las funciones miembro para verificar el estado del cálculo.

(estoy usando Python y el módulo unittest.)

class Train: 

    def __init__(self, options, points): 
     self._options = options 
     self._points = points 
     # other initializations 

    def run(self): 
     self._setup_mappings_dict() 
     self._setup_train_and_estimation_sets() 
     if self._options.estimate_method == 'per_class': 
      self._setup_priors() 
     self._estimate_all_mappings() 
     self._save_mappings() 

    def _estimate_all_mappings(): 
     # implementation, calls to methods in this class 

    #other method definitions 

Definitivamente tengo expectativas sobre lo que los estados de los miembros de los atributos deben estar antes y después de las llamadas a los diferentes métodos como parte de la implementación del método run(). ¿Debo hacer afirmaciones sobre estos atributos "privados"? No sé de qué otro modo probar estos métodos.

La otra opción es que realmente no debería probar estos.

+0

Algún código o pseudocódigo sería útil para comprender su pregunta. Según lo que has escrito, parece que puedes beneficiarte del método unittest.TestCase.setUp(). http://docs.python.org/library/unittest.html#unittest.TestCase.setUp – msw

+0

He editado su pregunta con el código que ha proporcionado. ¿Puedes verificar que la sangría sea correcta y volver a editarla si es necesario? –

+0

@ire_and_curses. Gracias, editado un poco. –

Respuesta

10

Responderé a mi propia pregunta. Después de leer y pensar un poco, creo que no debería probar las unidades de estos métodos privados. Debería probar la interfaz pública. Si los métodos privados que hacen el procesamiento interno son lo suficientemente importantes como para probarlos de manera independiente y no son solo coincidencias de la implementación actual, entonces tal vez esto sea una señal de que deberían refactorizarse en una clase separada.

+1

+1 para la auto-respuesta y una bastante buena en eso, si no es susceptible de pruebas unitarias, tal vez no sea una "unidad". – msw

6

Me gusta su respuesta, pero no estoy de acuerdo.

La situación en la que utilizaría este patrón de diseño es aquella en la que se está llevando a cabo una operación bastante compleja. Como resultado, ser capaz de verificar los componentes individuales de tal operación, diría que es altamente deseable.

A continuación, tiene la cuestión de las dependencias en otros recursos (que puede ser o no cierto en este caso).

Debe poder usar alguna forma de ioc para inyectar algún tipo de simulacro para aislar la clase.

Además de la mayoría de los marcos burlones le proporcionará accesoantes para llegar a los miembros privados.

+0

Gracias por esta vista alternativa. No estaba consciente de burlarme cuando hice esta pregunta. –

+1

También he cambiado de opinión desde entonces a uno más como el tuyo. Si necesita realizar una prueba privada, probablemente debería trasladarse a otra clase. Sin embargo, creo que mi idea aún se mantiene para las cosas que deberían ser internas, no privadas. –

Cuestiones relacionadas