diff options
Diffstat (limited to 'docs/topics/testing')
| -rw-r--r-- | docs/topics/testing/advanced.txt | 14 | ||||
| -rw-r--r-- | docs/topics/testing/overview.txt | 23 | ||||
| -rw-r--r-- | docs/topics/testing/tools.txt | 36 |
3 files changed, 10 insertions, 63 deletions
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt index f2a2b103fc..e230c2624d 100644 --- a/docs/topics/testing/advanced.txt +++ b/docs/topics/testing/advanced.txt @@ -415,10 +415,6 @@ execute and tear down the test suite. custom arguments by calling ``parser.add_argument()`` inside the method, so that the :djadmin:`test` command will be able to use those arguments. - .. versionchanged:: 1.8 - - The ``keepdb``, ``reverse``, and ``debug_sql`` arguments were added. - Attributes ~~~~~~~~~~ @@ -463,8 +459,6 @@ Methods .. classmethod:: DiscoverRunner.add_arguments(parser) - .. versionadded:: 1.8 - Override this class method to add custom arguments accepted by the :djadmin:`test` management command. See :py:meth:`argparse.ArgumentParser.add_argument()` for details about adding @@ -604,10 +598,6 @@ can be useful during testing. :setting:`NAME` in :setting:`DATABASES` to match the name of the test database. - .. versionchanged:: 1.8 - - The ``keepdb`` argument was added. - .. function:: destroy_test_db(old_database_name, verbosity=1, keepdb=False) Destroys the database whose name is the value of :setting:`NAME` in @@ -620,10 +610,6 @@ can be useful during testing. If the ``keepdb`` argument is ``True``, then the connection to the database will be closed, but the database will not be destroyed. - .. versionchanged:: 1.8 - - The ``keepdb`` argument was added. - .. _topics-testing-code-coverage: Integration with coverage.py diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt index fc18eb0e4a..06e6172724 100644 --- a/docs/topics/testing/overview.txt +++ b/docs/topics/testing/overview.txt @@ -135,13 +135,10 @@ Tests that require a database (namely, model tests) will not use your "real" Regardless of whether the tests pass or fail, the test databases are destroyed when all the tests have been executed. -.. versionadded:: 1.8 - - You can prevent the test databases from being destroyed by adding the - :djadminopt:`--keepdb` flag to the test command. This will preserve the test - database between runs. If the database does not exist, it will first - be created. Any migrations will also be applied in order to keep it - up to date. +You can prevent the test databases from being destroyed by adding the +:djadminopt:`--keepdb` flag to the test command. This will preserve the test +database between runs. If the database does not exist, it will first be +created. Any migrations will also be applied in order to keep it p to date. By default the test databases get their names by prepending ``test_`` to the value of the :setting:`NAME` settings for the databases @@ -173,10 +170,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. -.. versionadded:: 1.8 - - The ability to use SQLite with a shared cache as described above was added. - .. admonition:: Finding data from your production database when running tests? If your code attempts to access the database when its modules are compiled, @@ -218,11 +211,9 @@ the Django test runner reorders tests in the following way: database by a given :class:`~django.test.TransactionTestCase` test, they must be updated to be able to run independently. -.. versionadded:: 1.8 - - You may reverse the execution order inside groups by passing - :djadminopt:`--reverse` to the test command. This can help with ensuring - your tests are independent from each other. +You may reverse the execution order inside groups by passing +:djadminopt:`--reverse` to the test command. This can help with ensuring your +tests are independent from each other. .. _test-case-serialized-rollback: diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index 800f083765..0c97a67267 100644 --- a/docs/topics/testing/tools.txt +++ b/docs/topics/testing/tools.txt @@ -237,10 +237,6 @@ Use the ``django.test.Client`` class to make requests. You may also provide any file-like object (e.g., :class:`~io.StringIO` or :class:`~io.BytesIO`) as a file handle. - .. versionadded:: 1.8 - - The ability to use a file-like object was added. - Note that if you wish to use the same file handle for multiple ``post()`` calls then you will need to manually reset the file pointer between posts. The easiest way to do this is to @@ -321,8 +317,6 @@ Use the ``django.test.Client`` class to make requests. .. method:: Client.trace(path, follow=False, secure=False, **extra) - .. versionadded:: 1.8 - Makes a TRACE request on the provided ``path`` and returns a ``Response`` object. Useful for simulating diagnostic probes. @@ -496,8 +490,6 @@ Specifically, a ``Response`` object has the following attributes: .. attribute:: resolver_match - .. versionadded:: 1.8 - An instance of :class:`~django.core.urlresolvers.ResolverMatch` for the response. You can use the :attr:`~django.core.urlresolvers.ResolverMatch.func` attribute, for @@ -698,14 +690,6 @@ transaction, as is required when using :meth:`~django.db.models.query.QuerySet.select_for_update()`. In those cases, you should use ``TransactionTestCase``. -.. versionchanged:: 1.8 - - In older versions of Django, the effects of transaction commit and rollback - could not be tested within a ``TestCase``. With the completion of the - deprecation cycle of the old-style transaction management in Django 1.8, - transaction management commands (e.g. ``transaction.commit()``) are no - longer disabled within ``TestCase``. - ``TransactionTestCase`` and ``TestCase`` are identical except for the manner in which the database is reset to a known state and the ability for test code to test the effects of commit and rollback: @@ -759,8 +743,6 @@ additions, including: .. classmethod:: TestCase.setUpTestData() - .. versionadded:: 1.8 - The class-level ``atomic`` block described above allows the creation of initial data at the class level, once for the whole ``TestCase``. This technique allows for faster tests as compared to using ``setUp()``. @@ -1433,11 +1415,9 @@ your test suite. The name is a string such as ``'admin/index.html'``. - .. versionadded:: 1.8 - - The count argument is an integer indicating the number of times the - template should be rendered. Default is ``None``, meaning that the - template should be rendered one or more times. + The count argument is an integer indicating the number of times the + template should be rendered. Default is ``None``, meaning that the template + should be rendered one or more times. You can use this as a context manager, like this:: @@ -1562,8 +1542,6 @@ your test suite. .. method:: SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None) - .. versionadded:: 1.8 - Asserts that the JSON fragments ``raw`` and ``expected_data`` are *not* equal. See :meth:`~SimpleTestCase.assertJSONEqual` for further details. @@ -1724,10 +1702,6 @@ it would under MySQL with MyISAM tables):: # ... conditional test code pass -.. versionchanged:: 1.8 - - ``skipIfDBFeature`` can accept multiple feature strings. - .. function:: skipUnlessDBFeature(*feature_name_strings) Skip the decorated test or ``TestCase`` if any of the named database features @@ -1742,7 +1716,3 @@ under MySQL with MyISAM tables):: def test_transaction_behavior(self): # ... conditional test code pass - -.. versionchanged:: 1.8 - - ``skipUnlessDBFeature`` can accept multiple feature strings. |