#36083: LiveServerTestCase fails in parallel test runner if
django.contrib.auth.backends has not yet been imported
-------------------------------------+-------------------------------------
Reporter: Adam Zapletal | Owner: (none)
Type: Bug | Status: new
Component: Testing framework | Version: dev
Severity: Release blocker | Resolution:
Keywords: TransactionTestCase | Triage Stage: Accepted
setupclass available_apps |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jacob Walls):
Thanks Adam.
> Is there a way to implement this system check without the side effect?
To find out whether a middleware class declared by a string is a subclass
of something else, I think we have to import the string.
I may have skewed things by using the phrase "side effect": I think it's
good to admit flexibility in the order by which modules are imported. As
the long as the module-level caches are designed well, then in practice
it's not really a problem. It does raise test isolation concerns.
The test framework goes to great effort to reset the database layer
between tests, but the python layer is left up to the user. It might be
worthy to try out adding an `--isolate-imports` flag to the test runner in
a third-party package that would reset `sys.modules` between test case
classes. (I don't know if there's a test framework out there that already
implements such a thing.)
Here is where I would cc Adam Johnson if I had the right permission bit.
> Should the test itself be questioned?
Thanks for the grep -- it's true Django itself only has one test case
class in this situation, but a user could be doing this. I think there
would have been a similar problem with `SeleniumTestCase` if it were
supported by the parallel test runner. (It doesn't today but might in the
future.)
> This seems like a simple band-aid fix that would work for now if this
ticket has a deadline.
I tenatively marked this as a release blocker since it smelled like a
regression in Django 5.2: your test case class breaks if it depends on
`django.contrib.auth` via `LiveServerTestCase` (or `SeleniumTestCase` if
they have a way to run it in parallel or skip checks) but sets
`available_apps = []`. The wrinkle being that `available_apps` is a
private API we can change at will. I'll let the fellows speak to urgency.
> Option 3 feels more semantically correct but would need some thought
around the design to make it ergonomic (fiddling with this in every
subclass doesn't seem right)
We could also just doc that `LiveServerTestCase` subclasses should be
careful to to include auth in available_apps, given we've already
documented this as an advanced/private feature. Or add fanciness to to
`LiveServerTestCase._pre_setup()` to sniff for this misconfiguration, but
the complexity tradeoff looks bad if we need to be resilient against
subclasses of the auth middleware (hence the whole reason for
`_subclass_index` in the system check in the first place).
> 2. This seems like a simple band-aid fix that would work for now if this
ticket has a deadline. I'm not sure of all the implications here.
Re: shuffling the cheese around in `LiveServerTestCase.setUpClass()`, I
guess it has the benefit of clarifying that `available_apps` is really
only about signals and the database layer, and we could say that it's not
a way to adjust the app registry for other purposes like skipping imports.
----
I'm fine with any of the three options. Would like to hear from others.
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:5>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/010701945b1ce3d1-8cd3f964-1dd0-42ec-8347-f30fd9b3be00-000000%40eu-central-1.amazonses.com.
