#17365: Extend test discovery to include unittest2 test suite runner
-----------------------------------+------------------------------------
Reporter: jezdez | Owner: myusuf3
Type: New feature | Status: new
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+------------------------------------
Changes (by jezdez):
* stage: Ready for checkin => Accepted
Comment:
Moving back to accepted as Carl mentioned in the pull request over at
Github:
Sorry I haven't done a fuller comment on this sooner. I worked on this
some at the DjangoCon sprints and talked it over quite a bit with Russ,
Jacob, and others. I have some work locally but haven't pushed it yet
since it's not yet in a fully working state. I'll try to clean that work
up and get it pushed soon. Specifically the things that IMO are not ready
yet with this patch:
@jacobian wanted to avoid adding any new settings with this; things like
the test discovery pattern should be set instead as command-line
arguments.
If we are deprecating the old runner, it's no good to have the new
runner inherit from the deprecated runner; that's just postponing a bunch
of work to whoever does the final deprecation removal, deprecation
removals should not require big code reorganizations. Instead the new
runner needs to be standalone with all required functionality, and the old
runner should inherit from the new runner, so when it is removed nothing
else is affected.
Docs - I don't think we should commit things without adequate docs and
then clean it up later. Writing the docs helps us figure out if we've made
mistakes in the API. Docs are a first-class citizen.
The current code does a kind of funny thing where it tries to
intelligently decide whether to use discovery or loadTestsFromModule
depending what you pass on the command line and what it finds there. I did
this because it was functional and what I wanted for an external project,
but I'm not sure this approach belongs in Django - this is just going
right back down the path of inventing our own unique discovery process. I
think we should maybe stick closer to the native behavior of unittest, and
discuss with voidspace possible improvements to that behavior. This
requires more discussion.
And that's really the key - while I'd like to see this change in Django,
it's a significant developer-facing change and I think it's worth taking
the time to make sure we do it right. And that means not committing
something quick before feature freeze just to get it in, it means plenty
of time for consideration and review on django-developers. Unfortunately I
didn't have time this summer to drive that, but I'm hoping I (or someone
else?) will in the 1.6 cycle.
--
Ticket URL: <https://code.djangoproject.com/ticket/17365#comment:33>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
