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 , 9 years ago
Triage Stage: | Unreviewed → Someday/Maybe |
---|
comment:2 by , 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 , 9 years ago
We don't treat 2.0 as a special release, it's just the one that comes after 1.11.
unittest2pytest is off-topic: the idea of this ticket isn't to change the tests, it's to change the runner.
comment:4 by , 8 years ago
Version: | 1.8 → master |
---|
comment:5 by , 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 , 4 years ago
Cc: | added |
---|
comment:8 by , 4 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Triage Stage: | Someday/Maybe → Unreviewed |
Closing as wontfix
after discussion on the mailing list.
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.