Haz todo lo posible por entender el código correctamente previamente a adaptarlo a tu proyecto si tquieres aportar algo puedes compartirlo con nosotros.
Solución:
¿Es este el uso correcto de conftest.py?
Sí lo es. Los accesorios son un uso potencial y común de conftest.py
. Los accesorios que defina se compartirán entre todas las pruebas en su suite de pruebas. Sin embargo, definir accesorios en la raíz conftest.py
podría ser inútil y ralentizaría las pruebas si dichos accesorios no se utilizan en todas las pruebas.
¿Tiene otros usos?
Si lo hace.
-
Accesorios: Define accesorios para static datos utilizados por las pruebas. Todas las pruebas de la suite pueden acceder a estos datos, a menos que se especifique lo contrario. Esto podría ser tanto datos como ayudantes de módulos que se pasarán a todas las pruebas.
-
Carga de complementos externos:
conftest.py
se utiliza para importar módulos o complementos externos. Al definir la siguiente variable global, pytest cargará el módulo y lo pondrá a disposición para su prueba. Los complementos son generalmente archivos definidos en su proyecto u otros módulos que pueden ser necesarios en sus pruebas. También puede cargar un conjunto de complementos predefinidos como se explica aquí.pytest_plugins = "someapp.someplugin"
-
Manos: Puede especificar enlaces como los métodos de instalación y desmontaje y mucho más para mejorar sus pruebas. Para obtener un conjunto de ganchos disponibles, lea aquí. Ejemplo:
def pytest_runtest_setup(item): """ called before ``pytest_runtest_call(item). """ #do some stuff`
-
Probar ruta raíz: Esta es una característica un poco oculta. Definiendo
conftest.py
en tu ruta raíz, tendráspytest
reconocer los módulos de su aplicación sin especificarPYTHONPATH
. En segundo plano, py.test modifica susys.path
incluyendo todos los submódulos que se encuentran en la ruta raíz.
¿Puedo tener más de un archivo conftest.py?
Sí, puede y se recomienda encarecidamente si su estructura de prueba es algo compleja. conftest.py
los archivos tienen alcance de directorio. Por lo tanto, la creación de accesorios y ayudantes específicos es una buena práctica.
¿Cuándo querría hacer eso? Se apreciarán ejemplos.
Varios casos podrían encajar:
Creando un conjunto de herramientas o manos para un grupo particular de pruebas.
root / mod / conftest.py
def pytest_runtest_setup(item):
print("I am mod")
#do some stuff
test root/mod2/test.py will NOT produce "I am mod"
Cargando un conjunto de accesorios para algunas pruebas pero no para otras.
root / mod / conftest.py
@pytest.fixture()
def fixture():
return "some stuff"
root / mod2 / conftest.py
@pytest.fixture()
def fixture():
return "some other stuff"
root / mod2 / test.py
def test(fixture):
print(fixture)
Imprimirá “algunas otras cosas”.
Primordial ganchos heredados de la raíz conftest.py
.
root / mod / conftest.py
def pytest_runtest_setup(item):
print("I am mod")
#do some stuff
root / conftest.py
def pytest_runtest_setup(item):
print("I am root")
#do some stuff
Al ejecutar cualquier prueba en el interior root/mod
, sólo se imprime “Soy mod”.
Puedes leer más sobre conftest.py
aquí.
EDITAR:
¿Qué sucede si necesito que se invoquen funciones de ayuda antiguas desde varias pruebas en diferentes módulos? ¿Estarán disponibles para mí si las coloco en un conftest.py? ¿O debería simplemente ponerlos en un módulo helpers.py e importarlo y usarlo en mis módulos de prueba?
Puedes usar conftest.py
para definir a tus ayudantes. Sin embargo, debe seguir la práctica habitual. Los ayudantes se pueden utilizar como accesorios al menos en pytest
. Por ejemplo, en mis pruebas tengo un simulacro de ayuda de redis que inyecto en mis pruebas de esta manera.
root / helper / redis / redis.py
@pytest.fixture
def mock_redis():
return MockRedis()
root / tests / stuff / conftest.py
pytest_plugin="helper.redis.redis"
root / tests / stuff / test.py
def test(mock_redis):
print(mock_redis.get('stuff'))
Este será un módulo de prueba que puede importar libremente en sus pruebas. NOTA que potencialmente podrías nombrar redis.py
como conftest.py
si tu modulo redis
contiene más pruebas. Sin embargo, esa práctica se desaconseja debido a la ambigüedad.
Si quieres usar conftest.py
, simplemente puede poner ese ayudante en su raíz conftest.py
e inyectarlo cuando sea necesario.
root / tests / conftest.py
@pytest.fixture
def mock_redis():
return MockRedis()
root / tests / stuff / test.py
def test(mock_redis):
print(mock_redis.get(stuff))
Otra cosa que puede hacer es escribir un complemento instalable. En ese caso, su ayudante se puede escribir en cualquier lugar, pero debe definir un punto de entrada para ser instalado en su y otros marcos de prueba potenciales. Mira esto.
Si no desea usar accesorios, por supuesto, podría definir un ayudante simple y simplemente usar la importación simple y antigua donde sea que sea necesario.
root / tests / helper / redis.py
class MockRedis():
# stuff
root / tests / stuff / test.py
from helper.redis import MockRedis
def test():
print(MockRedis().get(stuff))
Sin embargo, aquí puede tener problemas con la ruta, ya que el módulo no está en una carpeta secundaria de la prueba. Debería poder superar esto (no probado) agregando un __init__.py
a tu ayudante
root / tests / helper / __ init__.py
from .redis import MockRedis
O simplemente agregando el módulo de ayuda a su PYTHONPATH
.
En un sentido amplio conftest.py
es un complemento local por directorio. Aquí define ganchos y accesorios específicos del directorio. En mi caso, tengo un directorio raíz que contiene directorios de pruebas específicos del proyecto. Alguna magia común está estacionada en ‘raíz’ conftest.py
. Proyecto específico – en los propios. No veo nada malo en almacenar accesorios en conftest.py
a menos que no se utilicen ampliamente (en ese caso, prefiero definirlos en archivos de prueba directamente)
Yo uso el
conftest.py
para definir los accesorios que inyecto en mis pruebas, ¿es este el uso correcto deconftest.py
?
sí, un accesorio se usa generalmente para preparar los datos para múltiples pruebas.
¿Tiene otros usos?
sí, un accesorio es una función que ejecuta pytest
antes y, a veces, después de las funciones de prueba reales. El código del dispositivo puede hacer lo que quieras. Por ejemplo, se puede usar un dispositivo para obtener un conjunto de datos para que funcionen las pruebas, o también se puede usar un dispositivo para poner un sistema en un estado conocido antes de ejecutar una prueba.
¿Puedo tener más de uno?
conftest.py
¿expediente? ¿Cuándo querría hacer eso?
Primero, es posible colocar accesorios en archivos de prueba individuales. Sin embargo, para compartir dispositivos entre varios archivos de prueba, debe utilizar un conftest.py
archivo en algún lugar central para todas las pruebas. Los accesorios pueden ser compartidos por cualquier prueba. Se pueden colocar en archivos de prueba individuales si desea que el dispositivo solo sea utilizado por pruebas en ese archivo.
Segundo, sí, puedes tener otro conftest.py
archivos en subdirectorios del directorio superior de pruebas. Si lo hace, los accesorios definidos en estos niveles inferiores conftest.py
Los archivos estarán disponibles para las pruebas en ese directorio y subdirectorios.
Finalmente, colocando accesorios en el conftest.py
archivo en la raíz de prueba los hará disponibles en todos los archivos de prueba.
Al final de la post puedes encontrar las observaciones de otros gestores de proyectos, tú aún eres capaz insertar el tuyo si te apetece.