#32939: Change override_settings to do its subclass check lazily
-------------------------------------+-------------------------------------
Reporter: Chris Jerdonek | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Testing framework | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Chris Jerdonek:
Old description:
> Currently, the `@override_settings` decorator raises a `ValueError` if
> it's used to decorate a class that doesn't inherit from `SimpleTestCase`:
> https://github.com/django/django/blob/56f9579105c324ff15250423bf9f8bdf1634cfb4/django/test/utils.py#L519-L521
>
> However, this prevents the decorator from being useable as a test-class
> mixin for a number of `SimpleTestCase` subclasses. When creating shared
> test-class functionality, it's often better to use a mixin rather than a
> concrete `TestCase` class. This way the mixin won't have its `setUp`
> methods run unnecessarily on a test-case class with no tests, and it
> won't count towards the parallel test runner's test-case class count,
> etc.
>
> The check could instead be done lazily, e.g. inside `setUpClass()`, while
> still having the same desired effect.
>
> I noticed this when seeing if I could convert `AuthViewsTestCase` into a
> mixin:
> https://github.com/django/django/blob/56f9579105c324ff15250423bf9f8bdf1634cfb4/tests/auth_tests/test_views.py
> The `AuthViewsTestCase` change could be done in a nicer way once this
> ticket is implemented, perhaps even as part of this ticket.
New description:
Currently, the `@override_settings` decorator raises a `ValueError` if
it's used to decorate a class that doesn't inherit from `SimpleTestCase`:
https://github.com/django/django/blob/56f9579105c324ff15250423bf9f8bdf1634cfb4/django/test/utils.py#L519-L521
However, this prevents the decorator from being useable as a test-class
mixin for a number of `SimpleTestCase` subclasses. When creating shared
test-class functionality, it's often better to use a mixin rather than a
concrete `TestCase` class. This way the mixin won't have its `setUp`
methods run unnecessarily on a test-case class with no tests, and it won't
count towards the parallel test runner's test-case class count, etc.
The check could instead be done lazily, e.g. inside `setUpClass()`, while
still having the same desired effect.
I noticed this when seeing if I could convert
[https://github.com/django/django/blob/56f9579105c324ff15250423bf9f8bdf1634cfb4/tests/auth_tests/test_views.py#L46
AuthViewsTestCase] into a mixin. This `AuthViewsTestCase` change could be
done in a nicer way once this ticket is implemented, perhaps even as part
of this ticket.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32939#comment:2>
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 on the web visit
https://groups.google.com/d/msgid/django-updates/067.6a75a82d4dba6e5d8c01fb4df723e4f8%40djangoproject.com.
