Opened 2 years ago

Last modified 14 months ago

#25707 new New feature

Use py.test for internal testing

Reported by: Olivier Le Thanh Duong Owned by: nobody
Component: Testing framework Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


pytest (or py.test ) offer some nice options that the current 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 (4)

comment:1 Changed 2 years ago by Carl Meyer

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 Changed 2 years ago by Asif Saifuddin Auvi

better to be considered for 2.0+ series.

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

comment:3 Changed 2 years ago by Aymeric Augustin

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.

Last edited 2 years ago by Tim Graham (previous) (diff)

comment:4 Changed 14 months ago by Asif Saifuddin Auvi

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