¿Cómo usar pdb.set_trace() en un test de Django?

debugging django-testing

Question

Quiero depurar un Django TestCase como lo haría con cualquier otro código Python: Simplemente llame a pdb.set_trace() y luego pdb.set_trace() a una sesión interactiva. Cuando hago eso, no veo nada, ya que las pruebas se ejecutan en un proceso diferente. Estoy usando django-discover-runner , pero supongo que esto se aplica al corredor de prueba de Django predeterminado.

La pregunta:

¿Es posible ingresar a una sesión de pdb mientras se usa django-discover-runner a) en cada error / fail, AND / OR b) solo cuando llamo a pdb.set_trace() en mi código de prueba?

Alguna investigación:

Esta respuesta explica que Django crea otro proceso y sugiere usar una llamada al rpdb2 debugger , una parte de winpdb , pero no quiero usar winpdb , prefiero usar ipdb .

Esta respuesta resuelve el problema para django-nose ejecutando el comando de prueba de esta manera: ./manage.py test -- -s , pero esa opción no está disponible para django-discover-runner .

Esta respuesta muestra que puedo hacer esto con ipython :

In [9]: %pdb
Automatic pdb calling has been turned ON

Esa parece una opción potencial, pero parece un poco engorroso disparar ipython cada vez que ejecuto pruebas.

Finalmente, esta respuesta muestra que la nose viene con un indicador --pdb que cae en pdb en los errores, que es lo que quiero. ¿Es mi única opción cambiar al corredor de prueba django-nose ?

No veo ninguna opción para esto en la ayuda integrada para django-discover-runner :

$ python manage.py help test --settings=settings.test
Usage: manage.py test [options] [appname ...]

Runs the test suite for the specified applications, or the entire site if no apps are specified.

Options:
  -v VERBOSITY, --verbosity=VERBOSITY
                        Verbosity level; 0=minimal output, 1=normal output,
                        2=verbose output, 3=very verbose output
  --settings=SETTINGS   The Python path to a settings module, e.g.
                        "myproject.settings.main". If this isn''t provided, the
                        DJANGO_SETTINGS_MODULE environment variable will be
                        used.
  --pythonpath=PYTHONPATH
                        A directory to add to the Python path, e.g.
                        "/home/djangoprojects/myproject".
  --traceback           Print traceback on exception
  --noinput             Tells Django to NOT prompt the user for input of any
                        kind.
  --failfast            Tells Django to stop running the test suite after
                        first failed test.
  --testrunner=TESTRUNNER
                        Tells Django to use specified test runner class
                        instead of the one specified by the TEST_RUNNER
                        setting.
  --liveserver=LIVESERVER
                        Overrides the default address where the live server
                        (used with LiveServerTestCase) is expected to run
                        from. The default value is localhost:8081.
  -t TOP_LEVEL, --top-level-directory=TOP_LEVEL
                        Top level of project for unittest discovery.
  -p PATTERN, --pattern=PATTERN
                        The test matching pattern. Defaults to test*.py.
  --version             show program''s version number and exit
  -h, --help            show this help message and exit

Answer 1

Django no ejecuta pruebas en un proceso separado; La respuesta enlazada que afirma que lo hace es simplemente errónea. (El más cercano es el LiveServerTestCase para las pruebas de Selenium, que inicia un subproceso independiente para ejecutar el servidor de desarrollo, pero todavía no es un proceso separado y no impide el uso de pdb). Debes poder insertar import pdb; pdb.set_trace() import pdb; pdb.set_trace() en cualquier parte de una prueba (o en el código probado) y obtenga un indicador de pdb utilizable. Nunca tuve problemas con esto, y lo verifiqué nuevamente en un proyecto nuevo con Django 1.5.1 y django-discover-runner 1.0. Si esto no funciona para usted, se debe a otra cosa en su proyecto, no a Django o django-discover-runner.

Nose captura todos los resultados por defecto, lo que rompe la import pdb; pdb.set_trace() import pdb; pdb.set_trace() . La opción -s desactiva la captura de salida. Esto no es necesario con el corredor de prueba de Django o el corredor de descubrimiento de Django, ya que ninguno de ellos realiza la captura de salida para empezar.

No conozco ningún equivalente a la opción --pdb de --pdb si estás usando django-discover-runner. Hay un proyecto django-pdb que proporciona esto, pero una rápida lectura de su código me sugiere que no jugaría bien con django-discover-runner; Sin embargo, su código podría darle algunas pistas para implementar esto usted mismo.

FWIW, personalmente uso py.test con pytest-django lugar de django-discover-runner o django-nose. Y aunque py.test proporciona una opción --pdb como nose, no la uso; A menudo, quiero romper antes del punto de error real para pasar por la ejecución antes del error, por lo que normalmente solo inserto import pytest; pytest.set_trace() import pytest; pytest.set_trace() (la importación de set_trace desde pytest hace el equivalente a la opción -s de nose; desactiva la captura de salida de py.test antes de ejecutar pdb) donde lo quiero en el código y luego lo elimino cuando termine. No encuentro esto oneroso; YMMV.

Answer 2

Trate de usar ipdb en lugar de pdb -

import ipdb;ipdb.set_trace()

o (funciona en caso de corredor de prueba de nariz)

from nose.tools import set_trace;set_trace()