Opened 73 minutes ago
#37080 new Cleanup/optimization
Django's own tests should always treat both Django deprecation warnings as errors
| Reported by: | Mike Edmunds | Owned by: | |
|---|---|---|---|
| Component: | Testing framework | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Django's runtests.py treats RemovedAfterNextVersionWarning (currently equivalent to RemovedInDjango70Warning) as an error, in all releases. And in x.0 and x.2 releases, it also treats RemovedInNextVersionWarning as an error.
However, in x.1 releases RemovedInNextVersionWarning is not handled as an error (because there is no RemovedInDjango62Warning, or any x.2 equivalent).
This doesn't matter for most Django tests, which use the concrete RemovedInDjango70Warning, RemovedInDjango71Warning, etc. But it complicates testing Django's own deprecation utilities and assertion helpers, and it makes discussions of them complicated.
Suggestion: change runtests.py to use the generic warnings and treat them both as errors—always, without the need to advance them each release:
# Before: warnings.simplefilter("error", RemovedInDjango70Warning) # After warnings.simplefilter("error", RemovedInNextVersionWarning) warnings.simplefilter("error", RemovedAfterNextVersionWarning)
(I think this becomes moot if/when we switch to calendar cycle releases.)