Skip to content

Loading…

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

Closed
wants to merge 3 commits into from

2 participants

@marfire

Common testing tools - in particular, the ones referenced in the tutorial
and in the testing overview - were made importable from django.test.
The documentation was cleaned up to consistently refer to these
tools as being part of django.test.

Note that I did not adjust all the internal references (in Django's own test code) to use this path. I can do that, but I'm not sure if it's necessary or desirable.

See ticket #19885.

@marfire marfire Fixed #19885 - cleaned up the django.test namespace
Common testing tools - in particular, the ones referenced in the tutorial
and in the testing overview - were made importable from django.test.
The documentation was cleaned up to consistently refer to these
tools as being part of django.test.
d6e0250
@timgraham timgraham commented on the diff
docs/topics/testing/advanced.txt
@@ -5,18 +5,18 @@ Advanced testing topics
The request factory
===================
-.. module:: django.test.client
+.. currentmodule:: django.test
@timgraham Django member

the next ".. currentmodule:: django.test" can be removed since it's redundant with this change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@timgraham timgraham commented on an outdated diff
docs/topics/testing/overview.txt
@@ -313,8 +313,7 @@ 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.
+.. currentmodule:: django.test
@timgraham Django member

looks like this can be omitted -- the module is already django.test

similarly, the next ".. currentmodule:: django.test" in the doc is no longer needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@timgraham timgraham commented on an outdated diff
docs/topics/testing/overview.txt
@@ -1330,17 +1328,16 @@ 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
+.. currentmodule:: django.test
@timgraham Django member

not needed and remove next occurrence of ".. currentmodule:: django.test"

we should also have a ..versionchanged:: 1.7 note here that it had to be imported from utils in previous versions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@marfire marfire Made changes suggested by Tim Graham
- Removed unnecessary currentmodule directives
- Added a versionchanged directive for override_settings()
7449874
@marfire

@timgraham Thanks for your comments, I made the suggested changes.

@timgraham
Django member

There are still quite a few errors (broken links) when building the docs after this change - could you fix them?

@marfire

Sorry, missed those warnings in the Sphinx output...

@timgraham
Django member

merge in 9d70032 - thanks!

@timgraham timgraham closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Sep 9, 2013
  1. @marfire

    Fixed #19885 - cleaned up the django.test namespace

    marfire committed
    Common testing tools - in particular, the ones referenced in the tutorial
    and in the testing overview - were made importable from django.test.
    The documentation was cleaned up to consistently refer to these
    tools as being part of django.test.
  2. @marfire

    Made changes suggested by Tim Graham

    marfire committed
    - Removed unnecessary currentmodule directives
    - Added a versionchanged directive for override_settings()
  3. @marfire
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
@timgraham Django member

the next ".. currentmodule:: django.test" can be removed since it's redundant with this change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
.. 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
Something went wrong with that request. Please try again.