sqlite - setup - ¿Qué hacer cuando un py.test cuelga en silencio?
pytest (5)
Al usar py.test , tengo algunas pruebas que funcionan bien con SQLite pero que cuelgan silenciosamente cuando cambio a Postgresql. ¿Cómo haría para depurar algo así? ¿Hay un modo "detallado" en el que pueda ejecutar mis pruebas o establecer un punto de interrupción? De manera más general, ¿cuál es el plan estándar de ataque cuando Pytest se detiene en silencio? He intentado usar el pytest-timeout y ejecuté la prueba con $ py.test --timeout = 300, pero las pruebas aún se cuelgan sin ninguna actividad en la pantalla.
En mi caso, la aplicación Flask no if __name__ == ''__main__'':
así que ejecutó app.start()
cuando esa no era mi intención.
Puedes leer muchos más detalles here .
Me encontré con el mismo problema de SQLite / Postgres con Flask y SQLAlchemy, similar a Gordon Fierce. Sin embargo, mi solución fue diferente. Postgres es estricto con respecto a los bloqueos y las conexiones de la tabla, por lo que cerrar explícitamente la conexión de la sesión en el desmontaje solucionó el problema para mí.
Mi código de trabajo:
@pytest.yield_fixture(scope=''function'')
def db(app):
# app is an instance of a flask app, _db a SQLAlchemy DB
_db.app = app
with app.app_context():
_db.create_all()
yield _db
# Explicitly close DB connection
_db.session.close()
_db.drop_all()
Referencia de SQLAlchemy: http://docs.sqlalchemy.org/en/rel_0_8/faq.html#my-program-is-hanging-when-i-say-table-drop-metadata-drop-all
No sabiendo lo que se está rompiendo en el código, la mejor manera es aislar la prueba que está fallando y establecer un punto de interrupción en él para echar un vistazo. Nota: uso pudb en lugar de pdb, porque es realmente la mejor manera de depurar python si no está utilizando un IDE.
Por ejemplo, puede hacer lo siguiente en su archivo de prueba:
import pudb
...
def test_create_product(session):
pudb.set_trace()
# Create the Product instance
# Create a Price instance
# Add the Product instance to the session.
...
Entonces ejecútalo con
py.test -s --capture=no test_my_stuff.py
Ahora podrá ver exactamente dónde se bloquea el script y examinar la pila y la base de datos en este momento particular de ejecución. De lo contrario es como buscar una aguja en un pajar.
Para responder a la pregunta "¿Cómo voy a depurar algo así?"
Ejecute con py.test -m trace --trace para obtener un seguimiento de las llamadas de python.
Una opción (útil para cualquier binario de Unix atascado) es adjuntar al proceso usando
strace -p <PID>
. Vea en qué llamada del sistema podría estar bloqueado o en un bucle de llamadas al sistema. por ejemplo, atascado llamando a gettimeofdayPara una salida más detallada de py.test instale pytest-sugar.
pip install pytest-sugar
y ejecuta la prueba conpytest.py --verbose . . .
pytest.py --verbose . . .
https://pypi.python.org/pypi/pytest-sugar
Tuve un problema similar con pytest y Postgresql mientras probaba una aplicación Flask que usaba SQLAlchemy. Parece que Pytest tiene dificultades para ejecutar un desmontaje utilizando su método request.addfinalizer con Postgresql.
Anteriormente tuve:
@pytest.fixture
def db(app, request):
def teardown():
_db.drop_all()
_db.app = app
_db.create_all()
request.addfinalizer(teardown)
return _db
(_db es una instancia de SQLAlchemy Importe desde extensions.py) Pero si descarto la base de datos cada vez que se llama al dispositivo de la base de datos:
@pytest.fixture
def db(app, request):
_db.app = app
_db.drop_all()
_db.create_all()
return _db
Entonces pytest no se cuelga después de tu primera prueba.