[Django] #28452: Consider adding a test command argument --locals to show traceback locals
Django
---------------------------------------------+------------------------
Reporter: David Sanders | Owner: nobody
Type: New feature | Status: new
Component: Testing framework | Version: 1.11
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------------+------------------------
I'd like to suggest adding an argument to the test command, `--locals`,
that simply passes `tb_locals=True` to `unittest.TextTestRunner()`.
Currently it looks as though support for adding custom test runner kwargs
was improved in 1.11 with ticket #26981 whereby one can provide a custom
test runner and override `get_test_runner_kwargs()` however I think it
would be nice to be able to examine locals without having to setup a
custom test runner.
--
Ticket URL: <https://code.djangoproject.com/ticket/28452>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: David Sanders | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by David Sanders):
* version: 1.11 => master
Old description:
> I'd like to suggest adding an argument to the test command, `--locals`,
> that simply passes `tb_locals=True` to `unittest.TextTestRunner()`.
>
> Currently it looks as though support for adding custom test runner kwargs
> was improved in 1.11 with ticket #26981 whereby one can provide a custom
> test runner and override `get_test_runner_kwargs()` however I think it
> would be nice to be able to examine locals without having to setup a
> custom test runner.
New description:
I'd like to suggest adding an argument to the test command, `--locals`,
that simply passes `tb_locals=True` to `unittest.TextTestRunner()`.
Currently it looks as though support for adding custom test runner kwargs
was improved in 1.11 with ticket #26981 whereby one can provide a custom
test runner and override `get_test_runner_kwargs()` however I think it
would be nice to be able to examine locals without having to setup a
custom test runner.
Please note that the `tb_locals` argument was introduced in Python 3.5, so
this would need to be taken into consideration.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/28452#comment:1>
Django
Reporter: David Sanders | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by David Sanders):
Comment from jtiai on #django:
> About #28452 Well it might generate quite lot of output and it
potentially can output secrets that you don't want to leak out.
--
Ticket URL: <https://code.djangoproject.com/ticket/28452#comment:2>
Django
Reporter: David Sanders | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham):
There might be some risk of heading down the path of reimplementing many
features of [https://docs.pytest.org/en/latest/usage.html#modifying-
python-traceback-printing pytest]. How do we decide which of those
features to add to Django?
--
Ticket URL: <https://code.djangoproject.com/ticket/28452#comment:3>
Django
Reporter: David Sanders | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* stage: Unreviewed => Someday/Maybe
Comment:
It would probably be best to reach a consensus on the
DevelopersMailingList before proceeding.
--
Ticket URL: <https://code.djangoproject.com/ticket/28452#comment:4>
Django
Reporter: David Sanders | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Adam (Chainz) Johnson):
> Well it might generate quite lot of output
A valid concern, but normally more output is better for debugging. Most
functions have a handful of locals. Pytest shows locals by default as
well, so there's a precedent.
> it potentially can output secrets that you don't want to leak out.
I don't think this is much of a concern, normally those with the ability
to see test results already have the ability to see or run the test code,
and thus find the secrets. Additionally, many test assertions already can
output secrets.
> There might be some risk of heading down the path of reimplementing many
features of pytest.
I agree, we don't want Django's test framework to reinvent the wheel. But
this feature is only providing the ability to use something already within
unittest.
I'd be in favour of passing `tb_locals=True` always, instead of adding a
flag to make it optional. Using a flag would make the feature hard to
discover feature and "yet another thing to think about." Users can
override the test runner themselves as shown to undo this change if they
want.
--
Ticket URL: <https://code.djangoproject.com/ticket/28452#comment:5>
Django
Type: New feature | Status: new
Keywords: | Triage Stage:
| Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Ülgen Sarıkavak):
* cc: Ülgen Sarıkavak (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/28452#comment:6>