Opened 9 years ago

Closed 4 years ago

#25707 closed New feature (wontfix)

Use py.test for internal testing

Reported by: Olivier Le Thanh Duong Owned by: nobody
Component: Testing framework Version: dev
Severity: Normal Keywords:
Cc: אורי, Petr Přikryl Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

pytest (or py.test ) offer some nice options that the current runtests.py script does not, for example: dropping into a debugger in case of error or a more accurate tests selection and more readable error reporting.
It also allow custom plugin and validation (e.g. pep8 and flake) and is becoming more and more standard in the Python community so new comer could use a tool they already know how to use.

So maybe we should discuss using it instead of the current homegrown solution?

Change History (8)

comment:1 by Carl Meyer, 9 years ago

Triage Stage: UnreviewedSomeday/Maybe

I've certainly had the same thought; in the abstract, I don't think it makes much sense for us to be maintaining our own test runner atop unittest when there are well-maintained existing runners with similar features. But unless we are ready to tell the entire Django community they must start using py.test, the change would need to only affect internal testing. In that case we are still maintaining a custom test runner (for users of Django), just no longer dogfooding it ourselves. That seems like an unfortunate situation, and not much of a win. We have a lot of test utilities which in a pytest world ought to be rewritten as pytest fixtures, but then they are no longer available to non-pytest users.

So I can't really see how the change practically works until/unless we are ready to just say "the blessed way of doing all Django testing is with py.test." I'd be ok with that in theory - I think py.test is a very good test runner, and it could be seen as another svn/git/hg situation, where we should just make a choice (even if controversial) rather than muddling along with the lowest common denominator. But it would be the second recent big breaking change to testing (1.6 DiscoverRunner being the last); I don't want to put the community through another change like that right now, and I don't think the support is there in the core team to do it. (It's a bigger change in a way than svn/git/hg, since that one didn't affect non-contributor users at all).

So, reluctantly, I have to say that despite some possible benefits, I don't think this is likely to happen anytime soon. Moving into the Someday/maybe category.

comment:2 by Asif Saifuddin Auvi, 9 years ago

better to be considered for 2.0+ series.

on that occasion unittest2pytest automated converted could be a help. [official tool]

comment:3 by Aymeric Augustin, 9 years ago

We don't treat 2.0 as a special release, it's just the one that comes after 1.10.

unittest2pytest is off-topic: the idea of this ticket isn't to change the tests, it's to change the runner.

Version 0, edited 9 years ago by Aymeric Augustin (next)

comment:4 by Asif Saifuddin Auvi, 8 years ago

Version: 1.8master

comment:5 by Daniel Hahler, 5 years ago

For reference: I've started working on this a while ago, see https://code.djangoproject.com/ticket/30415.
I was using a custom pytest plugin (that Django would ship itself), and using a refactored runtests.py to re-use the same code Django uses currently.[

comment:6 by אורי, 4 years ago

Cc: אורי added

comment:7 by Petr Přikryl, 4 years ago

Cc: Petr Přikryl added

comment:8 by Mariusz Felisiak, 4 years ago

Resolution: wontfix
Status: newclosed
Triage Stage: Someday/MaybeUnreviewed

Closing as wontfix after discussion on the mailing list.

Note: See TracTickets for help on using tickets.
Back to Top