mirror of
https://github.com/django/django.git
synced 2025-08-31 15:57:45 +00:00
Removed versionadded/changed notes for 1.7.
This commit is contained in:
Tim Graham
parent
0e60912492
commit
c79faae761
64 changed files with 100 additions and 864 deletions
|
|
@ -414,16 +414,12 @@ Attributes
|
|||
|
||||
.. attribute:: DiscoverRunner.test_suite
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The class used to build the test suite. By default it is set to
|
||||
``unittest.TestSuite``. This can be overridden if you wish to implement
|
||||
different logic for collecting tests.
|
||||
|
||||
.. attribute:: DiscoverRunner.test_runner
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This is the class of the low-level test runner which is used to execute
|
||||
the individual tests and format the results. By default it is set to
|
||||
``unittest.TextTestRunner``. Despite the unfortunate similarity in
|
||||
|
|
@ -594,11 +590,9 @@ can be useful during testing.
|
|||
``False`` to speed up creation time if you don't have any test classes
|
||||
with :ref:`serialized_rollback=True <test-case-serialized-rollback>`.
|
||||
|
||||
.. versionadded:: 1.7.1
|
||||
|
||||
If you are using the default test runner, you can control this with the
|
||||
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the
|
||||
:setting:`TEST <DATABASE-TEST>` dictionary
|
||||
If you are using the default test runner, you can control this with the
|
||||
the :setting:`SERIALIZE <TEST_SERIALIZE>` entry in the :setting:`TEST
|
||||
<DATABASE-TEST>` dictionary.
|
||||
|
||||
``keepdb`` determines if the test run should use an existing
|
||||
database, or create a new one. If ``True``, the existing
|
||||
|
|
@ -612,10 +606,6 @@ can be useful during testing.
|
|||
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
|
||||
database.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The ``serialize`` argument was added.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
The ``keepdb`` argument was added.
|
||||
|
|
|
|||
|
|
@ -152,10 +152,8 @@ entirely!). If you want to use a different database name, specify
|
|||
:setting:`NAME <TEST_NAME>` in the :setting:`TEST <DATABASE-TEST>`
|
||||
dictionary for any given database in :setting:`DATABASES`.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
On PostgreSQL, :setting:`USER` will also need read access to the built-in
|
||||
``postgres`` database.
|
||||
On PostgreSQL, :setting:`USER` will also need read access to the built-in
|
||||
``postgres`` database.
|
||||
|
||||
Aside from using a separate database, the test runner will otherwise
|
||||
use all of the same database settings you have in your settings file:
|
||||
|
|
@ -175,12 +173,6 @@ If using a SQLite in-memory database with Python 3.4+ and SQLite 3.7.13+,
|
|||
`shared cache <https://www.sqlite.org/sharedcache.html>`_ will be enabled, so
|
||||
you can write tests with ability to share the database between threads.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The different options in the :setting:`TEST <DATABASE-TEST>` database
|
||||
setting used to be separate options in the database settings dictionary,
|
||||
prefixed with ``TEST_``.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
The ability to use SQLite with a shared cache as described above was added.
|
||||
|
|
@ -194,10 +186,8 @@ you can write tests with ability to share the database between threads.
|
|||
your tests. *It is a bad idea to have such import-time database queries in
|
||||
your code* anyway - rewrite your code so that it doesn't do this.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
This also applies to customized implementations of
|
||||
:meth:`~django.apps.AppConfig.ready()`.
|
||||
This also applies to customized implementations of
|
||||
:meth:`~django.apps.AppConfig.ready()`.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
|||
|
|
@ -130,10 +130,6 @@ Use the ``django.test.Client`` class to make requests.
|
|||
|
||||
.. method:: Client.get(path, data=None, follow=False, secure=False, **extra)
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``secure`` argument was added.
|
||||
|
||||
Makes a GET request on the provided ``path`` and returns a ``Response``
|
||||
object, which is documented below.
|
||||
|
||||
|
|
@ -435,8 +431,6 @@ Specifically, a ``Response`` object has the following attributes:
|
|||
|
||||
.. attribute:: wsgi_request
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
The ``WSGIRequest`` instance generated by the test handler that
|
||||
generated the response.
|
||||
|
||||
|
|
@ -845,25 +839,15 @@ out the `full reference`_ for more details.
|
|||
.. _full reference: http://selenium-python.readthedocs.org/en/latest/api.html
|
||||
.. _Firefox: http://www.mozilla.com/firefox/
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
.. tip::
|
||||
|
||||
Before Django 1.7 ``LiveServerTestCase`` used to rely on the
|
||||
:doc:`staticfiles contrib app </howto/static-files/index>` to get the
|
||||
static assets of the application(s) under test transparently served at their
|
||||
expected locations during the execution of these tests.
|
||||
|
||||
In Django 1.7 this dependency of core functionality on a ``contrib``
|
||||
application has been removed, because of which ``LiveServerTestCase``
|
||||
ability in this respect has been retrofitted to simply publish the contents
|
||||
of the file system under :setting:`STATIC_ROOT` at the :setting:`STATIC_URL`
|
||||
URL.
|
||||
|
||||
If you use the ``staticfiles`` app in your project and need to perform live
|
||||
testing then you might want to consider using the
|
||||
If you use the :mod:`~django.contrib.staticfiles` app in your project and
|
||||
need to perform live testing, then you might want to use the
|
||||
:class:`~django.contrib.staticfiles.testing.StaticLiveServerTestCase`
|
||||
subclass shipped with it instead because it's the one that implements the
|
||||
original behavior now. See :ref:`the relevant documentation
|
||||
<staticfiles-testing-support>` for more details.
|
||||
subclass which transparently serves all the assets during execution of
|
||||
its tests in a way very similar to what we get at development time with
|
||||
``DEBUG=True``, i.e. without having to collect them using
|
||||
:djadmin:`collectstatic`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -1135,8 +1119,6 @@ in the ``with`` block and reset its value to the previous state afterwards.
|
|||
|
||||
.. method:: SimpleTestCase.modify_settings()
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
It can prove unwieldy to redefine settings that contain a list of values. In
|
||||
practice, adding or removing values is often sufficient. The
|
||||
:meth:`~django.test.SimpleTestCase.modify_settings` context manager makes it
|
||||
|
|
@ -1189,14 +1171,8 @@ The decorator can also be applied to :class:`~django.test.TestCase` classes::
|
|||
response = self.client.get('/sekrit/')
|
||||
self.assertRedirects(response, '/other/login/?next=/sekrit/')
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Previously, ``override_settings`` was imported from ``django.test.utils``.
|
||||
|
||||
.. function:: modify_settings
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Likewise, Django provides the :func:`~django.test.modify_settings`
|
||||
decorator::
|
||||
|
||||
|
|
@ -1265,11 +1241,6 @@ have been overridden, like this::
|
|||
del settings.LOGIN_URL
|
||||
...
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Previously, you could only simulate the deletion of a setting which was
|
||||
explicitly overridden.
|
||||
|
||||
When overriding settings, make sure to handle the cases in which your app's
|
||||
code uses a cache or similar feature that retains state even if the setting is
|
||||
changed. Django provides the :data:`django.test.signals.setting_changed`
|
||||
|
|
@ -1445,14 +1416,10 @@ your test suite.
|
|||
host (for example, initializing the test client with
|
||||
``Client(HTTP_HOST="testhost")``.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
If ``fetch_redirect_response`` is ``False``, the final page won't be
|
||||
loaded. Since the test client can't fetch externals URLs, this is
|
||||
particularly useful if ``expected_url`` isn't part of your Django app.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
Scheme is handled correctly when making comparisons between two URLs. If
|
||||
there isn't any scheme specified in the location where we are redirected to,
|
||||
the original request's scheme is used. If present, the scheme in
|
||||
|
|
@ -1564,11 +1531,6 @@ your test suite.
|
|||
|
||||
Output in case of error can be customized with the ``msg`` argument.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
The method now accepts a ``msg`` parameter to allow customization of
|
||||
error message
|
||||
|
||||
.. method:: TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)
|
||||
|
||||
Asserts that when ``func`` is called with ``*args`` and ``**kwargs`` that
|
||||
|
|
@ -1705,10 +1667,6 @@ it would under MySQL with MyISAM tables)::
|
|||
def test_transaction_behavior(self):
|
||||
# ... conditional test code
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``skipIfDBFeature`` can now be used to decorate a ``TestCase`` class.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``skipIfDBFeature`` can accept multiple feature strings.
|
||||
|
|
@ -1727,10 +1685,6 @@ under MySQL with MyISAM tables)::
|
|||
def test_transaction_behavior(self):
|
||||
# ... conditional test code
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
``skipUnlessDBFeature`` can now be used to decorate a ``TestCase`` class.
|
||||
|
||||
.. versionchanged:: 1.8
|
||||
|
||||
``skipUnlessDBFeature`` can accept multiple feature strings.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue