2012-09-25 13 views
42

Al usar py.test, dos pruebas llamadas de la misma manera en diferentes directorios hacen que py.test falle. ¿Porqué es eso? ¿Cómo puedo cambiar esto sin cambiar el nombre de todas las pruebas?py.test: prueba de detección fallida cuando las pruebas en directorios diferentes se llaman igual

Para duplicar hacer:

; cd /var/tmp/my_test_module 
; mkdir -p ook/test   
; mkdir -p eek/test 
; touch ook/test/test_proxy.py 
; touch eek/test/test_proxy.py 
; py.test 
============================= test session starts ============================== 
platform linux2 -- Python 2.7.3 -- pytest-2.2.4 
collected 0 items/1 errors 

==================================== ERRORS ==================================== 
___________________ ERROR collecting ook/test/test_proxy.py ____________________ 
import file mismatch: 
imported module 'test_proxy' has this __file__ attribute: 
    /home/ygolanski/code/junk/python/mymodule/eek/test/test_proxy.py 
which is not the same as the test file we want to collect: 
    /home/ygolanski/code/junk/python/mymodule/ook/test/test_proxy.py 
HINT: remove __pycache__/.pyc files and/or use a unique basename for your test file modules 
=========================== 1 error in 0.01 seconds ============================ 

Respuesta

30

poner __init__.py es una manera de resolver el conflicto. A diferencia de nose, el actual Pytest no intenta descargar módulos de prueba para importar módulos de prueba con el mismo nombre de importación. Solía ​​pensar que es un poco mágico hacer esto desimportar automáticamente y podría arruinar las expectativas de la gente sobre lo que hace el mecanismo de importación; a veces la gente confía en el estado global de un módulo de prueba y con la descarga automática lo pierde (un módulo de prueba importado desde otro módulo de prueba podría hacer cosas inesperadas). Pero tal vez no es un problema práctico y por lo tanto, Pytest podría agregar un truco similar ...

+2

Estoy de acuerdo en que la necesidad de un __init__.py tiene sentido. Si una prueba no está en un paquete, entonces es esencialmente un módulo de nivel superior (en el OP, test_proxy) y debería haber solo uno. Al colocar los módulos de prueba en paquetes relevantes (ook y eek), proporciona un espacio de nombres adecuado para las pruebas. Yo digo que el status quo es lo mejor. Podría aliviar el dolor tener el mensaje de error vinculado a esta pregunta o a algo en los documentos que explique el razonamiento y la técnica para solucionar el problema. –

+20

Solo una nota que py.test docs específicamente desaconseja poner '__init __. Py' en directorios de prueba: _" evite archivos '__init __. Py' en sus directorios de prueba. De esta manera sus pruebas pueden ejecutarse fácilmente contra una versión instalada de mypkg, independientemente de si el paquete instalado contiene las pruebas o no "_. Tomado de [pytest.org - Buenas prácticas de integración] (http://pytest.org/latest/goodpractises.html#choosing-a-test-layout-import-rules). – famousgarkin

+1

Actualización: La recomendación en el comentario de @ famousgarkin anterior y la respuesta (https://stackoverflow.com/a/21942491/260303) parece que ya no está en los documentos (al menos buscar "evitar" no muestra la cita arriba): https://docs.pytest.org/en/latest/goodpractices.html#tests-as-part-of-application-code. De hecho, los ejemplos en ese enlace muestran '__init __. Py' en los directorios de prueba, por lo que parece que la respuesta aceptada es la correcta. –

14

Esta es una característica real de py.test. Puede encontrar la razón de este comportamiento se indica en pytest.org - Good Integration Practices - Choosing a test layout/import rules:

  • evitar __init__.py archivos de los directorios de prueba. De esta manera, sus pruebas pueden ejecutarse fácilmente contra una versión instalada de mypkg, independientemente de si el paquete instalado contiene las pruebas o no.

Como ese es el flujo de trabajo recomendada de trabajar con py.test: instalar el paquete en fase de desarrollo con pip install -e, luego probarlo.

Debido a esto, yo mismo opto por nombres de prueba únicos, en la convención sobre la forma de configuración. También garantiza que no obtenga nombres de prueba ambiguos en los diversos resultados de ejecución de prueba.

Si necesita conservar los nombres de las pruebas y no se preocupan por la funcionalidad mencionada anteriormente, debería estar de acuerdo con poner un __init__.py.

+0

No aparece el caso de uso: "De esta manera, sus pruebas pueden ejecutarse fácilmente contra una versión instalada de mypkg". Ejecuto mis pruebas contra mi versión de desarrollo de 'mypkg'. De esta manera las pruebas existen. Creo archivos '__init __. Py' para evitar este mensaje de error" base de datos única ". – guettli

+1

Creé una solicitud de función para cambiar los documentos: https: // bitbucket.org/hpk42/pytest/issue/529/unique-basename-and -__ init__py-docs – guettli

+1

@guettli El caso de uso es cuando desea probar su paquete como instalado a través de setup.py. Esto se puede utilizar para asegurarse de incluir todos los archivos necesarios en la instalación, como los datos agrupados y que todas las dependencias se manejan correctamente. También se puede usar para instalar en entornos donde el sistema de destino no tiene un compilador y vas a utilizar un huevo binario o una rueda para la instalación. –

Cuestiones relacionadas