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.

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