Fixed #19885 -- cleaned up the django.test namespace

* override_settings may now be imported from django.test
* removed Approximate from django.test
* updated documentation for things importable from django.test

Thanks akaariai for the suggestion.

django/test/__init__.py

@@ -7,4 +7,4 @@ from django.test.testcases import (TestCase, TransactionTestCase,
     SimpleTestCase, LiveServerTestCase, skipIfDBFeature,
     skipUnlessDBFeature
 )
-from django.test.utils import Approximate
+from django.test.utils import override_settings

docs/internals/deprecation.txt

@@ -117,9 +117,9 @@ these changes.
 * The ``mod_python`` request handler will be removed. The ``mod_wsgi``
   handler should be used instead.
 
-* The ``template`` attribute on :class:`~django.test.client.Response`
+* The ``template`` attribute on :class:`~django.test.Response`
   objects returned by the :ref:`test client <test-client>` will be removed.
-  The :attr:`~django.test.client.Response.templates` attribute should be
+  The :attr:`~django.test.Response.templates` attribute should be
   used instead.
 
 * The ``django.test.simple.DjangoTestRunner`` will be removed.

docs/intro/tutorial05.txt

@@ -319,7 +319,7 @@ Before we try to fix anything, let's have a look at the tools at our disposal.
 The Django test client
 ----------------------
 
-Django provides a test :class:`~django.test.client.Client` to simulate a user
+Django provides a test :class:`~django.test.Client` to simulate a user
 interacting with the code at the view level.  We can use it in ``tests.py``
 or even in the shell.
 
@@ -341,7 +341,7 @@ Next we need to import the test client class (later in ``tests.py`` we will use
 the :class:`django.test.TestCase` class, which comes with its own client, so
 this won't be required)::
 
-    >>> from django.test.client import Client
+    >>> from django.test import Client
     >>> # create an instance of the client for our use
     >>> client = Client()
 

docs/ref/signals.txt

@@ -565,7 +565,7 @@ setting_changed
 
 This signal is sent when the value of a setting is changed through the
 ``django.test.TestCase.settings()`` context manager or the
-:func:`django.test.utils.override_settings` decorator/context manager.
+:func:`django.test.override_settings` decorator/context manager.
 
 It's actually sent twice: when the new value is applied ("setup") and when the
 original value is restored ("teardown"). Use the ``enter`` argument to

docs/releases/1.0-porting-guide.txt

@@ -643,7 +643,7 @@ The generic relation classes -- ``GenericForeignKey`` and ``GenericRelation``
 Testing
 -------
 
-:meth:`django.test.client.Client.login` has changed
+:meth:`django.test.Client.login` has changed
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Old (0.96)::

docs/releases/1.1-beta-1.txt

@@ -99,7 +99,7 @@ one fell swoop.
 Testing improvements
 --------------------
 
-.. currentmodule:: django.test.client
+.. currentmodule:: django.test
 
 A couple of small but very useful improvements have been made to the
 :doc:`testing framework </topics/testing/index>`:

docs/releases/1.1.txt

@@ -285,8 +285,6 @@ full description, and some important notes on database support.
 Test client improvements
 ------------------------
 
-.. currentmodule:: django.test.client
-
 A couple of small -- but highly useful -- improvements have been made to the
 test client:
 

docs/releases/1.2.2.txt

@@ -23,7 +23,7 @@ case of Django 1.2.2, we have made an exception to this rule.
 
 In order to test a bug fix that forms part of the 1.2.2 release, it
 was necessary to add a feature -- the ``enforce_csrf_checks`` flag --
-to the :mod:`test client <django.test.client>`. This flag forces
+to the :ref:`test client <test-client>`. This flag forces
 the test client to perform full CSRF checks on forms. The default
 behavior of the test client hasn't changed, but if you want to do
 CSRF checks with the test client, it is now possible to do so.

docs/releases/1.3-alpha-1.txt

@@ -150,7 +150,7 @@ requests. These include:
 * Improved tools for accessing and manipulating the current Site via
   ``django.contrib.sites.models.get_current_site()``.
 
-* A :class:`~django.test.client.RequestFactory` for mocking
+* A :class:`~django.test.RequestFactory` for mocking
   requests in tests.
 
 * A new test assertion --
@@ -318,7 +318,7 @@ Test client response ``template`` attribute
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Django's :ref:`test client <test-client>` returns
-:class:`~django.test.client.Response` objects annotated with extra testing
+:class:`~django.test.Response` objects annotated with extra testing
 information. In Django versions prior to 1.3, this included a ``template``
 attribute containing information about templates rendered in generating the
 response: either None, a single :class:`~django.template.Template` object, or a
@@ -327,7 +327,7 @@ return values (sometimes a list, sometimes not) made the attribute difficult
 to work with.
 
 In Django 1.3 the ``template`` attribute is deprecated in favor of a new
-:attr:`~django.test.client.Response.templates` attribute, which is always a
+:attr:`~django.test.Response.templates` attribute, which is always a
 list, even if it has only a single element or no elements.
 
 ``DjangoTestRunner``

docs/releases/1.3.txt

@@ -295,7 +295,7 @@ requests. These include:
   :class:`~django.contrib.sites.models.Site` object in
   :doc:`the sites framework </ref/contrib/sites>`.
 
-* A :class:`~django.test.client.RequestFactory` for mocking requests
+* A :class:`~django.test.RequestFactory` for mocking requests
   in tests.
 
 * A new test assertion --
@@ -715,7 +715,7 @@ Test client response ``template`` attribute
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Django's :ref:`test client <test-client>` returns
-:class:`~django.test.client.Response` objects annotated with extra testing
+:class:`~django.test.Response` objects annotated with extra testing
 information. In Django versions prior to 1.3, this included a ``template``
 attribute containing information about templates rendered in generating the
 response: either None, a single :class:`~django.template.Template` object, or a
@@ -724,7 +724,7 @@ return values (sometimes a list, sometimes not) made the attribute difficult
 to work with.
 
 In Django 1.3 the ``template`` attribute is deprecated in favor of a new
-:attr:`~django.test.client.Response.templates` attribute, which is always a
+:attr:`~django.test.Response.templates` attribute, which is always a
 list, even if it has only a single element or no elements.
 
 ``DjangoTestRunner``

docs/releases/1.4.6.txt

@@ -26,6 +26,6 @@ header and browsers seem to ignore JavaScript there.
 Bugfixes
 ========
 
-* Fixed an obscure bug with the :func:`~django.test.utils.override_settings`
+* Fixed an obscure bug with the :func:`~django.test.override_settings`
   decorator. If you hit an ``AttributeError: 'Settings' object has no attribute
   '_original_allowed_hosts'`` exception, it's probably fixed (#20636).

docs/releases/1.5.2.txt

@@ -57,6 +57,6 @@ Bugfixes
 * Ensured that the WSGI request's path is correctly based on the
   ``SCRIPT_NAME`` environment variable or the :setting:`FORCE_SCRIPT_NAME`
   setting, regardless of whether or not either has a trailing slash (#20169).
-* Fixed an obscure bug with the :func:`~django.test.utils.override_settings`
+* Fixed an obscure bug with the :func:`~django.test.override_settings`
   decorator. If you hit an ``AttributeError: 'Settings' object has no attribute
   '_original_allowed_hosts'`` exception, it's probably fixed (#20636).

docs/releases/1.6.txt

@@ -814,7 +814,7 @@ Miscellaneous
   ``{% url %}`` tag, it causes template rendering to fail like always when
   ``NoReverseMatch`` is raised.
 
-* :meth:`django.test.client.Client.logout` now calls
+* :meth:`django.test.Client.logout` now calls
   :meth:`django.contrib.auth.logout` which will send the
   :func:`~django.contrib.auth.signals.user_logged_out` signal.
 

docs/topics/auth/customizing.txt

@@ -869,8 +869,7 @@ would test three possible User models -- the default, plus the two User
 models provided by ``auth`` app::
 
     from django.contrib.auth.tests.utils import skipIfCustomUser
-    from django.test import TestCase
-    from django.test.utils import override_settings
+    from django.test import TestCase, override_settings
 
 
     class ApplicationTestCase(TestCase):

docs/topics/testing/advanced.txt

@@ -5,18 +5,18 @@ Advanced testing topics
 The request factory
 ===================
 
-.. module:: django.test.client
+.. currentmodule:: django.test
 
 .. class:: RequestFactory
 
-The :class:`~django.test.client.RequestFactory` shares the same API as
+The :class:`~django.test.RequestFactory` shares the same API as
 the test client. However, instead of behaving like a browser, the
 RequestFactory provides a way to generate a request instance that can
 be used as the first argument to any view. This means you can test a
 view function the same way as you would test any other function -- as
 a black box, with exactly known inputs, testing for specific outputs.
 
-The API for the :class:`~django.test.client.RequestFactory` is a slightly
+The API for the :class:`~django.test.RequestFactory` is a slightly
 restricted subset of the test client API:
 
 * It only has access to the HTTP methods :meth:`~Client.get()`,
@@ -38,8 +38,7 @@ Example
 The following is a simple unit test using the request factory::
 
     from django.contrib.auth.models import User
-    from django.test import TestCase
-    from django.test.client import RequestFactory
+    from django.test import TestCase, RequestFactory
 
     class SimpleTest(TestCase):
         def setUp(self):
@@ -165,8 +164,6 @@ exception will be raised.
 Advanced features of ``TransactionTestCase``
 ============================================
 
-.. currentmodule:: django.test
-
 .. attribute:: TransactionTestCase.available_apps
 
     .. versionadded:: 1.6

docs/topics/testing/overview.txt

@@ -313,9 +313,6 @@ Django provides a small set of tools that come in handy when writing tests.
 The test client
 ---------------
 
-.. module:: django.test.client
-   :synopsis: Django's test client.
-
 The test client is a Python class that acts as a dummy Web browser, allowing
 you to test your views and interact with your Django-powered application
 programmatically.
@@ -349,10 +346,10 @@ A comprehensive test suite should use a combination of both test types.
 Overview and a quick example
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To use the test client, instantiate ``django.test.client.Client`` and retrieve
+To use the test client, instantiate ``django.test.Client`` and retrieve
 Web pages::
 
-    >>> from django.test.client import Client
+    >>> from django.test import Client
     >>> c = Client()
     >>> response = c.post('/login/', {'username': 'john', 'password': 'smith'})
     >>> response.status_code
@@ -413,7 +410,7 @@ Note a few important things about how the test client works:
 Making requests
 ~~~~~~~~~~~~~~~
 
-Use the ``django.test.client.Client`` class to make requests.
+Use the ``django.test.Client`` class to make requests.
 
 .. class:: Client(enforce_csrf_checks=False, **defaults)
 
@@ -424,8 +421,8 @@ Use the ``django.test.client.Client`` class to make requests.
         >>> c = Client(HTTP_USER_AGENT='Mozilla/5.0')
 
     The values from the ``extra`` keywords arguments passed to
-    :meth:`~django.test.client.Client.get()`,
-    :meth:`~django.test.client.Client.post()`, etc. have precedence over
+    :meth:`~django.test.Client.get()`,
+    :meth:`~django.test.Client.post()`, etc. have precedence over
     the defaults passed to the class constructor.
 
     The ``enforce_csrf_checks`` argument can be used to test CSRF
@@ -778,7 +775,7 @@ Example
 The following is a simple unit test using the test client::
 
     import unittest
-    from django.test.client import Client
+    from django.test import Client
 
     class SimpleTest(unittest.TestCase):
         def setUp(self):
@@ -797,15 +794,13 @@ The following is a simple unit test using the test client::
 
 .. seealso::
 
-    :class:`django.test.client.RequestFactory`
+    :class:`django.test.RequestFactory`
 
 .. _django-testcase-subclasses:
 
 Provided test case classes
 --------------------------
 
-.. currentmodule:: django.test
-
 Normal Python unit test classes extend a base class of
 :class:`unittest.TestCase`. Django provides a few extensions of this base class:
 
@@ -847,7 +842,7 @@ functionality like:
     for equality.
 
 * The ability to run tests with :ref:`modified settings <overriding-settings>`.
-* Using the :attr:`~SimpleTestCase.client` :class:`~django.test.client.Client`.
+* Using the :attr:`~SimpleTestCase.client` :class:`~django.test.Client`.
 * Custom test-time :attr:`URL maps <SimpleTestCase.urls>`.
 
 .. versionchanged:: 1.6
@@ -1111,7 +1106,7 @@ worry about state (such as cookies) carrying over from one test to another.
 This means, instead of instantiating a ``Client`` in each test::
 
     import unittest
-    from django.test.client import Client
+    from django.test import Client
 
     class SimpleTest(unittest.TestCase):
         def test_details(self):
@@ -1146,8 +1141,7 @@ If you want to use a different ``Client`` class (for example, a subclass
 with customized behavior), use the :attr:`~SimpleTestCase.client_class` class
 attribute::
 
-    from django.test import TestCase
-    from django.test.client import Client
+    from django.test import TestCase, Client
 
     class MyTestClient(Client):
         # Specialized methods for your environment...
@@ -1330,17 +1324,14 @@ Django provides a standard Python context manager (see :pep:`343`)
 This example will override the :setting:`LOGIN_URL` setting for the code
 in the ``with`` block and reset its value to the previous state afterwards.
 
-.. currentmodule:: django.test.utils
-
 .. function:: override_settings
 
 In case you want to override a setting for just one test method or even the
 whole :class:`~django.test.TestCase` class, Django provides the
-:func:`~django.test.utils.override_settings` decorator (see :pep:`318`). It's
+:func:`~django.test.override_settings` decorator (see :pep:`318`). It's
 used like this::
 
-    from django.test import TestCase
-    from django.test.utils import override_settings
+    from django.test import TestCase, override_settings
 
     class LoginTestCase(TestCase):
 
@@ -1351,8 +1342,7 @@ used like this::
 
 The decorator can also be applied to test case classes::
 
-    from django.test import TestCase
-    from django.test.utils import override_settings
+    from django.test import TestCase, override_settings
 
     @override_settings(LOGIN_URL='/other/login/')
     class LoginTestCase(TestCase):
@@ -1361,6 +1351,11 @@ The decorator can also be applied to test case 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``.
+
 .. note::
 
     When given a class, the decorator modifies the class directly and
@@ -1427,8 +1422,6 @@ For more detail on email services during tests, see `Email services`_ below.
 Assertions
 ~~~~~~~~~~
 
-.. currentmodule:: django.test
-
 As Python's normal :class:`unittest.TestCase` class implements assertion methods
 such as :meth:`~unittest.TestCase.assertTrue` and
 :meth:`~unittest.TestCase.assertEqual`, Django's custom :class:`TestCase` class

tests/aggregation/tests.py

@@ -6,7 +6,8 @@ import re
 
 from django.db import connection
 from django.db.models import Avg, Sum, Count, Max, Min
-from django.test import TestCase, Approximate
+from django.test import TestCase
+from django.test.utils import Approximate
 from django.test.utils import CaptureQueriesContext
 
 from .models import Author, Publisher, Book, Store

tests/aggregation_regress/tests.py

@@ -8,7 +8,8 @@ from operator import attrgetter
 from django.core.exceptions import FieldError
 from django.contrib.contenttypes.models import ContentType
 from django.db.models import Count, Max, Avg, Sum, StdDev, Variance, F, Q
-from django.test import TestCase, Approximate, skipUnlessDBFeature
+from django.test import TestCase, skipUnlessDBFeature
+from django.test.utils import Approximate
 from django.utils import six
 
 from .models import (Author, Book, Publisher, Clues, Entries, HardbackBook,

tests/expressions_regress/tests.py

@@ -7,7 +7,8 @@ import datetime
 
 from django.db import connection
 from django.db.models import F
-from django.test import TestCase, Approximate, skipUnlessDBFeature
+from django.test import TestCase, skipUnlessDBFeature
+from django.test.utils import Approximate
 
 from .models import Number, Experiment
 

tests/serializers/tests.py

@@ -17,7 +17,8 @@ except ImportError:
 from django.conf import settings
 from django.core import management, serializers
 from django.db import transaction, connection
-from django.test import TestCase, TransactionTestCase, Approximate
+from django.test import TestCase, TransactionTestCase
+from django.test.utils import Approximate
 from django.utils import six
 from django.utils.six import StringIO