Skip to content

Conversation

goodtune
Copy link
Contributor

@goodtune goodtune commented Oct 2, 2025

  • Add DeprecationWarning to all response_###() methods
  • Migrate internal usage from response_###() to assert_http_###_<status_name>()
  • Add docstrings to all HTTP status code assertion methods
  • Add missing assertions per MDN HTTP status reference:
    • assert_http_103_early_hints()
    • assert_http_418_im_a_teapot()
    • assert_http_421_misdirected_request()
    • assert_http_425_too_early()
  • Exclude 102 Processing (WebDAV-specific, rarely used in Django apps)
  • Update documentation to reflect deprecation warnings

Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status

…ions

- Add `DeprecationWarning` to all `response_###()` methods
- Migrate internal usage from `response_###()` to `assert_http_###_<status_name>()`
- Add docstrings to all HTTP status code assertion methods
- Add missing assertions per MDN HTTP status reference:
  - `assert_http_103_early_hints()`
  - `assert_http_418_im_a_teapot()`
  - `assert_http_421_misdirected_request()`
  - `assert_http_425_too_early()`
- Exclude 102 Processing (WebDAV-specific, rarely used in Django apps)
- Update documentation to reflect deprecation warnings

Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
@frankwiles
Copy link
Member

While I can see assert_* being a more proper name for this, I think forcing everyone to change their existing tests by deprecating it a bit harsh. Wouldn't be opposed to duplicating the naming however, but maybe it should just be assert_402 rather than assert_http_402 just for brevity sake?

@goodtune
Copy link
Contributor Author

goodtune commented Oct 3, 2025

I originally set out to add a couple of response_XXX views that I was expecting, because I have been using that style forever. Claude knocked it out rapidly by giving it the MDN page as a reference.

However, just as I was about to create the pull request, I noticed the statement that these were deprecated in the documentation!

If they're not deprecated, I can add the response_XXX versions instead (and remove commentary from the documentation to that effect). If they are considered deprecated, then I think adding the warning lets folks know there is a preferred path without breaking things.

I don't mind either way - happy to work with whichever approach you would like.

That said, changing the alternative path from assert_http_XXX_status to assert_XXX I think would be even more disruptive, since that would introduce yet another path of deprecations or duplications...

@goodtune
Copy link
Contributor Author

goodtune commented Oct 3, 2025

I just did a dig back through the history on this (#86 and #102) and encountered 2019 @frankwiles : #86 (comment)

I don't really intend to deprecate them as much as keep both in parallel.

If you're still of that mind, I'll just go ahead and remove the documentation stating that they're deprecated and remove the warnings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants