unit - Prueba de unidad Python con configuración costosa

unittest python 3 (7)

Mi archivo de prueba es básicamente:

class Test(unittest.TestCase): def testOk(): pass if __name__ == "__main__": expensiveSetup() try: unittest.main() finally: cleanUp()

Sin embargo, deseo ejecutar mi prueba a través de las herramientas de prueba de Netbeans, y para hacer eso necesito tests de unidad que no dependan de una configuración de entorno realizada en main . Mirando el resultado de caché de setUp () usando Python unittest , recomienda usar Nose. Sin embargo, no creo que Netbeans lo apoye. No encontré ninguna información que indique que sí. Además, soy el único aquí en realidad escribiendo pruebas, por lo que no quiero introducir dependencias adicionales para los otros 2 desarrolladores a menos que sean necesarios.

¿Cómo puedo hacer la instalación y la limpieza una vez para todas las pruebas en mi TestSuite?

La costosa configuración aquí es la creación de algunos archivos con datos ficticios, así como la configuración y derribo de un simple servidor xml-rpc. También tengo 2 clases de prueba, una prueba local y una prueba de todos los métodos sobre xml-rpc.

Primero que nada, lo que dijo S. Lott. Sin embargo, no quieres hacer eso. Hay una razón por la cual setUp y tearDown se ajustan a cada prueba: ayudan a preservar el determinismo de las pruebas.

De lo contrario, si alguna prueba coloca al sistema en mal estado, las próximas pruebas pueden fallar. Idealmente, cada una de tus pruebas debería ser independiente.

Además, si insiste en hacerlo de esta manera, en lugar de escribir a mano self.runTest1 (), self.runTest2 (), es posible que desee hacer un poco de introspección para encontrar los métodos para ejecutar.

Puede asegurar que setUp y tearDown ejecuten una vez si solo tiene un método de prueba, runTest . Este método puede hacer lo que quiera. Solo asegúrate de no tener ningún método con nombres que comiencen con la test .

class MyExpensiveTest( unittest.TestCase ): def setUp( self ): self.resource = owThatHurts() def tearDown( self ): self.resource.flush() self.resource.finish() def runTest( self ): self.runTest1() self.tunTest2() def runTest1( self ): self.assertEquals(...) def runTest2( self ): self.assertEquals(...)

No encuentra automágicamente qué ejecutar. Si agrega un método de prueba, también debe actualizar runTest.

Puede guardar el estado si se ejecuta expensiveSetup() o no.

__expensiveSetup_has_run = False class ExpensiveSetupMixin(unittest.TestCase): def setUp(self): global __expensiveSetup_has_run super(ExpensiveSetupMixin, self).setUp() if __expensiveSetup_has_run is False: expensiveSetup() __expensiveSetup_has_run = True

O algún tipo de variación de esto. Tal vez hacer ping al servidor xml-rpc y crear uno nuevo si no está respondiendo.

Pero la forma de prueba de la unidad AFAIK es configurar y desmontar por unidad de prueba, incluso si es costoso.

No sé nada de Netbeans, pero creo que debería mencionar a zope.testrunner y su soporte para algo ingenioso: Capas. Básicamente, haces la prueba en clases separadas, y anexas esas clases a las pruebas. Estas clases pueden heredarse entre sí, formando una capa de configuraciones. El testrunner solo llamará a cada configuración una vez, y guardará el estado de eso en la memoria, y en lugar de configurar y destruir, simplemente copiará el contexto de la capa relevante como una configuración.

Esto acelera mucho la configuración de la prueba, y se usa cuando se prueban productos Zope y Plone, donde la prueba a menudo necesita que inicie un servidor Plone CMS, cree un sitio Plone y agregue un montón de contenido, un proceso que puede llevar hasta la mitad minuto. Hacer eso para cada método de prueba es obviamente imposible, pero con capas se hace solo una vez. Esto acorta la configuración de prueba y protege los métodos de prueba entre sí, y por lo tanto significa que las pruebas continúan siendo deterministas.

Así que no sé de zope.testrunner funcionará para ti, pero vale la pena intentarlo.

Si usa Python> = 2.7 (o unittest2 para Python> = 2.4 & <= 2.6), el mejor enfoque sería usar

def setUpClass(cls): # ... setUpClass = classmethod(setUpClass)

para realizar una inicialización una vez para todas las pruebas que pertenecen a la clase dada.

Y para realizar la limpieza, use:

@classmethod def tearDownClass(cls): # ...

Consulte también la documentación estándar de la biblioteca unittest sobre los métodos de clase setUpClass y tearDownClass .

Esto es lo que hago:

class TestSearch(unittest.TestCase): """General Search tests for....""" matcher = None counter = 0 num_of_tests = None def setUp(self): # pylint: disable-msg=C0103 """Only instantiate the matcher once""" if self.matcher is None: self.__class__.matcher = Matcher() self.__class__.num_of_tests = len(filter(self.isTestMethod, dir(self))) self.__class__.counter = self.counter + 1 def tearDown(self): # pylint: disable-msg=C0103 """And kill it when done""" if self.counter == self.num_of_tests: print ''KILL KILL KILL'' del self.__class__.matcher

Tristemente (porque quiero que mis pruebas sean independientes y deterministas), hago esto mucho (porque las pruebas del sistema que toman menos de 5 minutos también son importantes).

¿La inicialización del paquete no lo hará por usted? De la Wiki de la nariz :

nose permite que las pruebas se agrupen en paquetes de prueba. Esto permite la configuración a nivel de paquete; por ejemplo, si necesita crear una base de datos de prueba u otro accesorio de datos para sus pruebas, puede crearlo en la configuración del paquete y eliminarlo en el desmontaje del paquete una vez por prueba, en lugar de tener que crearlo y derribarlo una vez por módulo de prueba o caso de prueba.
Para crear métodos de configuración y desmontaje a nivel de paquete, defina las funciones de configuración y / o __init__.py en el __init__.py de un paquete de prueba. Los métodos de instalación pueden denominarse setup , setup_package , setUp o setUpPackage ; desmontaje se puede denominar teardown_package , tearDown , tearDown o tearDownPackage . La ejecución de las pruebas en un paquete de prueba comienza tan pronto como el primer módulo de prueba se carga desde el paquete de prueba.