mirror of
https://github.com/django/django.git
synced 2025-08-03 18:38:50 +00:00
Removed versionadded/changed annotations for 4.1.
This commit is contained in:
parent
ea92a4dc28
commit
490cccbe7e
49 changed files with 2 additions and 472 deletions
|
@ -331,10 +331,6 @@ or an unexpected success). If all the tests pass, the return code is 0. This
|
|||
feature is useful if you're using the test-runner script in a shell script and
|
||||
need to test for success or failure at that level.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, the return code was 0 for unexpected successes.
|
||||
|
||||
.. _speeding-up-tests-auth-hashers:
|
||||
|
||||
Speeding up the tests
|
||||
|
|
|
@ -1601,19 +1601,6 @@ your test suite.
|
|||
which means that ``errors='error message'`` is the same as
|
||||
``errors=['error message']``.
|
||||
|
||||
.. versionchanged:: 4.1
|
||||
|
||||
In older versions, using an empty error list with ``assertFormError()``
|
||||
would always pass, regardless of whether the field had any errors or
|
||||
not. Starting from Django 4.1, using ``errors=[]`` will only pass if
|
||||
the field actually has no errors.
|
||||
|
||||
Django 4.1 also changed the behavior of ``assertFormError()`` when a
|
||||
field has multiple errors. In older versions, if a field had multiple
|
||||
errors and you checked for only some of them, the test would pass.
|
||||
Starting from Django 4.1, the error list must be an exact match to the
|
||||
field's actual errors.
|
||||
|
||||
.. deprecated:: 4.1
|
||||
|
||||
Support for passing a response object and a form name to
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue