Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

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.
  • Loading branch information...
commit 9d700322b38ea670800a97f2b92dd2fc2c6ff28d 1 parent a52cc1c
@marfire marfire authored timgraham committed
View
2  django/test/__init__.py
@@ -7,4 +7,4 @@
SimpleTestCase, LiveServerTestCase, skipIfDBFeature,
skipUnlessDBFeature
)
-from django.test.utils import Approximate
+from django.test.utils import override_settings
View
4 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.
View
4 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()
View
2  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
View
2  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)::
View
2  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>`:
View
2  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:
View
2  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.
View
6 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``
View
6 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``
View
2  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).
View
2  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).
View
2  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.
View
3  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):
View
11 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
View
43 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
View
3  tests/aggregation/tests.py
@@ -6,7 +6,8 @@
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
View
3  tests/aggregation_regress/tests.py
@@ -8,7 +8,8 @@
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,
View
3  tests/expressions_regress/tests.py
@@ -7,7 +7,8 @@
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
View
3  tests/serializers/tests.py
@@ -17,7 +17,8 @@
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

0 comments on commit 9d70032

Please sign in to comment.
Something went wrong with that request. Please try again.