py.test: falla de descubrimiento de prueba cuando las pruebas en diferentes directorios se llaman igual

Al usar py.test, dos pruebas llamadas iguales en un directorio diferente hacen que py.test falle. ¿Porqué es eso? ¿Cómo puedo cambiar esto sin cambiar el nombre de todas las pruebas?

Para duplicar haz:

; 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 ============================ 

Poner un __init__.py es una forma de resolver el conflicto. A diferencia de la nariz, el pytest actual 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 de manera automática y podría arruinar las expectativas de las personas con respecto a lo que hace el mecanismo de importación; a veces las personas confían en el estado global de un módulo de prueba y con la descarga automática lo pierde (una importación de un módulo de prueba desde otro módulo de prueba podría hacer cosas inesperadas). Pero tal vez no sea un problema práctico y, por lo tanto, Pytest podría agregar un hack similar …

Esta es una característica real de py.test. Puede encontrar la razón de este comportamiento en pytest.org – Buenas prácticas de integración – Elegir un diseño de prueba / reglas de importación :

  • __init__.py 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.

Como ese es el flujo de trabajo recomendado para trabajar con py.test: instale el paquete en desarrollo con pip install -e , luego pruébelo.

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 mantener los nombres de las pruebas y no le importa la funcionalidad mencionada anteriormente, debería estar de acuerdo con poner un __init__.py .

Tuve el mismo error, pero la solución no tuvo nada que ver con los archivos de inicio ni el nombre en los archivos de prueba. Tuve diferentes versiones de python en mi macbook y en mi contenedor Docker . Inicié las pruebas una vez en el bash desde el macbook en la raíz del proyecto, en lugar del bash del contenedor.

La solución fue eliminar los archivos creados incorrectamente ejecutando (desde el bash del contenedor):

 find -name '*.pyc' -delete find -name __pycache__ -delete 

Luego inicie la prueba nuevamente (aún desde el bash del contenedor) y todo funcionó bien:

 py.test 

Puede agregar la siguiente variable de entorno a su archivo bash init o en otro lugar de su stack de desarrollo para evitar que estas carpetas / archivos se generen en primer lugar

 export PYTHONDONTWRITEBYTECODE=1