#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 Adam Zapletal):
Great job researching this, and thanks for the quick response!
For context, I found this issue while working on #10244, and this is not
my area of expertise in the codebase. However, here are my initial
thoughts on the options you presented:
1. Yes, the diff is a bit unfortunate, but running system checks in each
worker seems more correct to me if I'm understanding the design correctly.
It seems like we'd want to run them in every context or none.
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.
3. I agree that this seems correct in a way similar to the first option.
We don't want to evade system checks on accident.
----
I'm a bit thrown off by the fact that
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/django/contrib/auth/checks.py#L240-L262
the system check in question], via `_subclass_index`, has the side effect
of importing a module. I'm wondering the following:
1. Are there other system checks with side effects?
2. Is there a way to implement this system check without the side effect?
I'm not familiar enough with the system check framework to know what's
reasonable here, though I'd be interested to know.
----
This may be irrelevant, but if I grep the test suite for uses of
`LiveServerTestCase`, I find the following:
1. Tests testing aspects `LiveServerTestCase` itself (and
`StaticLiveServerTestCase`)
2.
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/tests/admin_scripts/tests.py#L2522-L2528
A test class] for the `startproject` command that sets `available_apps`
correctly
3.
[https://github.com/django/django/blob/8bee7fa45cd7bfe70b68784314e994e2d193fd70/tests/file_storage/tests.py#L1241
The file storage test class] that this ticket is about, which sets
`available_apps` to an empty list (for context, `available_apps` was set
[https://github.com/django/django/commit/c6e6d4eeb776c473567362405cdbc6a0328eb194
#diff-909f29df9f82791ff799d183cbcd685c30732b09822fc002a3b8df5df50d4883R625
here].)
So we can say that the test class in question is the only one in the whole
test suite that uses `LiveServerTestCase` but doesn't include
`django.contrib.auth` in `available_apps`. I'm not sure what that implies,
but this test is an outlier in multiple ways. Should the test itself be
questioned?
--
Ticket URL: <https://code.djangoproject.com/ticket/36083#comment:4>
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/01070194590d32cc-f8bb8bbe-e5f0-4f2b-956f-194742813b35-000000%40eu-central-1.amazonses.com.
