diff --git a/django/test/__init__.py b/django/test/__init__.py
index 7a4987508e6..58d54df5e20 100644
--- a/django/test/__init__.py
+++ b/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
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index 7b8298597d1..307f4dec646 100644
--- a/docs/internals/deprecation.txt
+++ b/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.
diff --git a/docs/intro/tutorial05.txt b/docs/intro/tutorial05.txt
index 1f0b40ed1d4..14a1795a1c2 100644
--- a/docs/intro/tutorial05.txt
+++ b/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()
 
diff --git a/docs/ref/signals.txt b/docs/ref/signals.txt
index 8381a49a094..fed8c7b3b5e 100644
--- a/docs/ref/signals.txt
+++ b/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
diff --git a/docs/releases/1.0-porting-guide.txt b/docs/releases/1.0-porting-guide.txt
index 644350525ca..5983e365fe9 100644
--- a/docs/releases/1.0-porting-guide.txt
+++ b/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)::
diff --git a/docs/releases/1.1-beta-1.txt b/docs/releases/1.1-beta-1.txt
index 88d8ce5f35c..6d45b9dfc97 100644
--- a/docs/releases/1.1-beta-1.txt
+++ b/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>`:
diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt
index 261b552aff7..e3ee9428bfe 100644
--- a/docs/releases/1.1.txt
+++ b/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:
 
diff --git a/docs/releases/1.2.2.txt b/docs/releases/1.2.2.txt
index 4ae74abbf9a..9c3054dc59c 100644
--- a/docs/releases/1.2.2.txt
+++ b/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.
diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt
index 634e6afaf2d..cb629a2cf83 100644
--- a/docs/releases/1.3-alpha-1.txt
+++ b/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``
diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt
index ecb48803a71..b77668ac3d2 100644
--- a/docs/releases/1.3.txt
+++ b/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``
diff --git a/docs/releases/1.4.6.txt b/docs/releases/1.4.6.txt
index 575e9fa75a5..3847ea26f94 100644
--- a/docs/releases/1.4.6.txt
+++ b/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).
diff --git a/docs/releases/1.5.2.txt b/docs/releases/1.5.2.txt
index 710f16555ce..20771365aa8 100644
--- a/docs/releases/1.5.2.txt
+++ b/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).
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 72d4df0feef..27c74825355 100644
--- a/docs/releases/1.6.txt
+++ b/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.
 
diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt
index bb44f091fe6..1407ed4d8f7 100644
--- a/docs/topics/auth/customizing.txt
+++ b/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):
diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt
index dc41747ae45..a4c425aeb9a 100644
--- a/docs/topics/testing/advanced.txt
+++ b/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
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index f5f8ad24c98..7c6f5caa47b 100644
--- a/docs/topics/testing/overview.txt
+++ b/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
diff --git a/tests/aggregation/tests.py b/tests/aggregation/tests.py
index ce7f4e9b9dd..5abd4aaf6c8 100644
--- a/tests/aggregation/tests.py
+++ b/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
diff --git a/tests/aggregation_regress/tests.py b/tests/aggregation_regress/tests.py
index 8388e78dbe3..b8ec14d1dc2 100644
--- a/tests/aggregation_regress/tests.py
+++ b/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,
diff --git a/tests/expressions_regress/tests.py b/tests/expressions_regress/tests.py
index c4f80858044..eb807cb050c 100644
--- a/tests/expressions_regress/tests.py
+++ b/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
 
diff --git a/tests/serializers/tests.py b/tests/serializers/tests.py
index 458847e4c76..34878adfd26 100644
--- a/tests/serializers/tests.py
+++ b/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