#37072: assertWarnsMessage() also ignores entire warning category
-------------------------------------+-------------------------------------
Reporter: Mike Edmunds | Owner: Artyom
| Kotovskiy
Type: Bug | Status: assigned
Component: Testing framework | Version: 6.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mike Edmunds):
Replying to [comment:7 Artyom Kotovskiy]:
> Am I missing something or those #37072 and #37076 are kind of
contradicting each other?
>
> We expect this to pass in #37076
>
> {{{
> def test_deprecated_in_my_app(self):
> with self.assertWarnsMessage(DeprecationWarning, "Deprecated in
MyApp"):
> warnings.warn("Deprecated in Django",
RemovedInNextVersionWarning)
> warnings.warn("Deprecated in MyApp", DeprecationWarning)
> }}}
>
> And this to fail in #37072.
>
>
>
> {{{
> def test_so_this_should_also_error_but_does_not(self):
> with self.assertWarnsMessage(RemovedInDjango70Warning, "Expected
deprecation"):
> warnings.warn("Expected deprecation",
RemovedInDjango70Warning)
> warnings.warn("Unrelated deprecation",
RemovedInDjango70Warning)
> }}}
>
>
> RemovedInNextVersionWarning is a subclass of DeprecationWarning. So as I
see it they both have same category, different message — but one should
pass and one should fail.
Django's runtests.py
[https://github.com/django/django/blob/9f790ef1a0f356cf6342b5d57bbaeac35aed0d9f/tests/runtests.py#L45-L50
converts some warnings to errors] within the tests. In particular,
RemovedInDjango70Warning is currently converted to an error, but the
current superclass PendingDeprecationWarning is not, and
RemovedInNextVersion warning is not. (There is no RemovedInDjango62Warning
due to a quirk of Django's deprecation cycles. If we did have that, it
would be equivalent to RemovedInNextVersionWarning, and runtests.py
''would'' convert RemovedInDjango62Warning to an error.)
So in Django's own tests, if both issues are fixed we'd expect:
- `test_so_this_should_also_error_but_does_not()` would ''error'' due to
the non-matching "Unrelated deprecation" message (converted to an error by
the runtests.py warning filters).
- `test_deprecated_in_my_app()` would pass (because of the matching
"Deprecated in MyApp") ''and'' might print "RemovedInNextVersionWarning:
Deprecated in Django" to the console, because runtests.py doesn't
currently convert RemovedInNextVersionWarning to an error. (But that will
change after 6.1 is released and runtests.py is updated for 6.2.)
The examples in the bug reports aren't good tests to add to Django itself:
they're a little ambiguous depending on how the testing environment is set
up, and they make assumptions about which Django warnings are currently
defined.
comment:1 suggests a `test_does_not_ignore_entire_category()` for #37072.
It uses an outer `assertRaisesMessage()` to verify "Unrelated deprecation"
makes it out of `assertWarnsMessage()` and is converted to an error by
runtests.py. (It also has a problem that I will fix in an edit.)
We'll need to craft a better test case for #37076 that takes all this into
account. You can rely on runtests.py always treating
RemovedAfterNextVersionWarning as an error (in all releases), and never
treating the base-class DeprecationWarning or PendingDeprecationWarning as
errors.
--
Ticket URL: <https://code.djangoproject.com/ticket/37072#comment:8>
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/0107019de4979e18-a8715a65-b24a-405a-b5a8-505103982fed-000000%40eu-central-1.amazonses.com.
