diff options
Diffstat (limited to 'docs/topics/testing')
| -rw-r--r-- | docs/topics/testing/advanced.txt | 16 | ||||
| -rw-r--r-- | docs/topics/testing/overview.txt | 18 | ||||
| -rw-r--r-- | docs/topics/testing/tools.txt | 60 |
3 files changed, 14 insertions, 80 deletions
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt index c995d5ec5c..3ca8ed88cf 100644 --- a/docs/topics/testing/advanced.txt +++ b/docs/topics/testing/advanced.txt @@ -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. diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt index 57bdfaa0ca..ac1c4b550e 100644 --- a/docs/topics/testing/overview.txt +++ b/docs/topics/testing/overview.txt @@ -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:: diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index 9d3ae456fd..a8637bf381 100644 --- a/docs/topics/testing/tools.txt +++ b/docs/topics/testing/tools.txt @@ -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 - - 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. +.. tip:: - 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. |