nose2 vs py.test con procesos aislados

Question

Hemos estado usando nosetest para ejecutar y recopilar nuestras pruebas de unidad (que están escritas como pruebas de unidad de python que nos gustan). Lo que más nos gusta de nose:

• usa pruebas de unidad de python estándar (nos gusta la estructura que esto impone).
• admite informes de cobertura y salida de prueba en xml (para jenkins).

Lo que nos falta es una buena forma de ejecutar pruebas en procesos aislados mientras mantenemos un buen repoorting de errores (estamos probando librerías C++ a través de python para que segfaults no sea catastrófico). nosepipe parece que ya no se mantiene y tenemos algunos problemas con él.

Estamos tratando de determinar si deberíamos - arreglar/usar la trompa nasal - cambiar a nose2 y escribir nosepipe2. - use Pytest o algún otro marco de prueba.

Preferiríamos utilizar un enfoque con una buena comunidad. Parece que nuestro problema (los complementos de C++ que requieren un buen aislamiento) podría ser un problema común, pero en Google no encontré soluciones que se mantengan. Asesoramiento de jefes más experimentados apreciado.

Answer 1

pytest tiene xdist plugin que proporciona la opción --boxed para ejecutar cada prueba en un subproceso controlado. Aquí está un ejemplo básico ::

# content of test_module.py 

import pytest 
import os 
import time 

# run test function 50 times with different argument 
@pytest.mark.parametrize("arg", range(50)) 
def test_func(arg): 
    time.sleep(0.05) # each tests takes a while 
    if arg % 19 == 0: 
     os.kill(os.getpid(), 15) 

Si ejecuta este con ::

$ py.test --boxed 
=========================== test session starts ============================ 
platform linux2 -- Python 2.7.3 -- pytest-2.3.0.dev8 
plugins: xdist, bugzilla, cache, oejskit, cli, pep8, cov 
collecting ... collected 50 items 

test_module.py f..................f..................f........... 

================================= FAILURES ================================= 
_______________________________ test_func[0] _______________________________ 
/home/hpk/tmp/doc-exec-420/test_module.py:6: running the test CRASHED with signal 15 
______________________________ test_func[19] _______________________________ 
/home/hpk/tmp/doc-exec-420/test_module.py:6: running the test CRASHED with signal 15 
______________________________ test_func[38] _______________________________ 
/home/hpk/tmp/doc-exec-420/test_module.py:6: running the test CRASHED with signal 15 
=================== 3 failed, 47 passed in 3.41 seconds ==================== 

Vas a ver que un par de pruebas se reportan como estrellarse, se indica por minúscula y f el respectivo resumen de falla. También puede utilizar la función de paralelización xdist-proporcionada para acelerar su prueba ::

$ py.test --boxed -n3 
=========================== test session starts ============================ 
platform linux2 -- Python 2.7.3 -- pytest-2.3.0.dev8 
plugins: xdist, bugzilla, cache, oejskit, cli, pep8, cov 
gw0 I/gw1 I/gw2 I 
gw0 [50]/gw1 [50]/gw2 [50] 

scheduling tests via LoadScheduling 
..f...............f..................f............ 
================================= FAILURES ================================= 
_______________________________ test_func[0] _______________________________ 
[gw0] linux2 -- Python 2.7.3 /home/hpk/venv/1/bin/python 
/home/hpk/tmp/doc-exec-420/test_module.py:6: running the test CRASHED with signal 15 
______________________________ test_func[19] _______________________________ 
[gw2] linux2 -- Python 2.7.3 /home/hpk/venv/1/bin/python 
/home/hpk/tmp/doc-exec-420/test_module.py:6: running the test CRASHED with signal 15 
______________________________ test_func[38] _______________________________ 
[gw2] linux2 -- Python 2.7.3 /home/hpk/venv/1/bin/python 
/home/hpk/tmp/doc-exec-420/test_module.py:6: running the test CRASHED with signal 15 
=================== 3 failed, 47 passed in 2.03 seconds ==================== 

En principio, simplemente distribuir en paralelo subprocesos pueden ser suficientes frecuencia y evita la sobrecarga de iniciar un proceso de caja para cada prueba. Actualmente, esto solo funciona si solo tiene menos pruebas de bloqueo que el número -n de procesos porque un proceso de prueba de extinción no se reinicia. Esta limitación probablemente podría eliminarse sin demasiado esfuerzo. Mientras tanto, deberás usar la opción de boxeo seguro.