Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

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
Kevin Christopher Henry authored timgraham committed
2  django/test/__init__.py
@@ -7,4 +7,4 @@
7 7
     SimpleTestCase, LiveServerTestCase, skipIfDBFeature,
8 8
     skipUnlessDBFeature
9 9
 )
10  
-from django.test.utils import Approximate
  10
+from django.test.utils import override_settings
4  docs/internals/deprecation.txt
@@ -117,9 +117,9 @@ these changes.
117 117
 * The ``mod_python`` request handler will be removed. The ``mod_wsgi``
118 118
   handler should be used instead.
119 119
 
120  
-* The ``template`` attribute on :class:`~django.test.client.Response`
  120
+* The ``template`` attribute on :class:`~django.test.Response`
121 121
   objects returned by the :ref:`test client <test-client>` will be removed.
122  
-  The :attr:`~django.test.client.Response.templates` attribute should be
  122
+  The :attr:`~django.test.Response.templates` attribute should be
123 123
   used instead.
124 124
 
125 125
 * The ``django.test.simple.DjangoTestRunner`` will be removed.
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.
319 319
 The Django test client
320 320
 ----------------------
321 321
 
322  
-Django provides a test :class:`~django.test.client.Client` to simulate a user
  322
+Django provides a test :class:`~django.test.Client` to simulate a user
323 323
 interacting with the code at the view level.  We can use it in ``tests.py``
324 324
 or even in the shell.
325 325
 
@@ -341,7 +341,7 @@ Next we need to import the test client class (later in ``tests.py`` we will use
341 341
 the :class:`django.test.TestCase` class, which comes with its own client, so
342 342
 this won't be required)::
343 343
 
344  
-    >>> from django.test.client import Client
  344
+    >>> from django.test import Client
345 345
     >>> # create an instance of the client for our use
346 346
     >>> client = Client()
347 347
 
2  docs/ref/signals.txt
@@ -565,7 +565,7 @@ setting_changed
565 565
 
566 566
 This signal is sent when the value of a setting is changed through the
567 567
 ``django.test.TestCase.settings()`` context manager or the
568  
-:func:`django.test.utils.override_settings` decorator/context manager.
  568
+:func:`django.test.override_settings` decorator/context manager.
569 569
 
570 570
 It's actually sent twice: when the new value is applied ("setup") and when the
571 571
 original value is restored ("teardown"). Use the ``enter`` argument to
2  docs/releases/1.0-porting-guide.txt
@@ -643,7 +643,7 @@ The generic relation classes -- ``GenericForeignKey`` and ``GenericRelation``
643 643
 Testing
644 644
 -------
645 645
 
646  
-:meth:`django.test.client.Client.login` has changed
  646
+:meth:`django.test.Client.login` has changed
647 647
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
648 648
 
649 649
 Old (0.96)::
2  docs/releases/1.1-beta-1.txt
@@ -99,7 +99,7 @@ one fell swoop.
99 99
 Testing improvements
100 100
 --------------------
101 101
 
102  
-.. currentmodule:: django.test.client
  102
+.. currentmodule:: django.test
103 103
 
104 104
 A couple of small but very useful improvements have been made to the
105 105
 :doc:`testing framework </topics/testing/index>`:
2  docs/releases/1.1.txt
@@ -285,8 +285,6 @@ full description, and some important notes on database support.
285 285
 Test client improvements
286 286
 ------------------------
287 287
 
288  
-.. currentmodule:: django.test.client
289  
-
290 288
 A couple of small -- but highly useful -- improvements have been made to the
291 289
 test client:
292 290
 
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.
23 23
 
24 24
 In order to test a bug fix that forms part of the 1.2.2 release, it
25 25
 was necessary to add a feature -- the ``enforce_csrf_checks`` flag --
26  
-to the :mod:`test client <django.test.client>`. This flag forces
  26
+to the :ref:`test client <test-client>`. This flag forces
27 27
 the test client to perform full CSRF checks on forms. The default
28 28
 behavior of the test client hasn't changed, but if you want to do
29 29
 CSRF checks with the test client, it is now possible to do so.
6  docs/releases/1.3-alpha-1.txt
@@ -150,7 +150,7 @@ requests. These include:
150 150
 * Improved tools for accessing and manipulating the current Site via
151 151
   ``django.contrib.sites.models.get_current_site()``.
152 152
 
153  
-* A :class:`~django.test.client.RequestFactory` for mocking
  153
+* A :class:`~django.test.RequestFactory` for mocking
154 154
   requests in tests.
155 155
 
156 156
 * A new test assertion --
@@ -318,7 +318,7 @@ Test client response ``template`` attribute
318 318
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
319 319
 
320 320
 Django's :ref:`test client <test-client>` returns
321  
-:class:`~django.test.client.Response` objects annotated with extra testing
  321
+:class:`~django.test.Response` objects annotated with extra testing
322 322
 information. In Django versions prior to 1.3, this included a ``template``
323 323
 attribute containing information about templates rendered in generating the
324 324
 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
327 327
 to work with.
328 328
 
329 329
 In Django 1.3 the ``template`` attribute is deprecated in favor of a new
330  
-:attr:`~django.test.client.Response.templates` attribute, which is always a
  330
+:attr:`~django.test.Response.templates` attribute, which is always a
331 331
 list, even if it has only a single element or no elements.
332 332
 
333 333
 ``DjangoTestRunner``
6  docs/releases/1.3.txt
@@ -295,7 +295,7 @@ requests. These include:
295 295
   :class:`~django.contrib.sites.models.Site` object in
296 296
   :doc:`the sites framework </ref/contrib/sites>`.
297 297
 
298  
-* A :class:`~django.test.client.RequestFactory` for mocking requests
  298
+* A :class:`~django.test.RequestFactory` for mocking requests
299 299
   in tests.
300 300
 
301 301
 * A new test assertion --
@@ -715,7 +715,7 @@ Test client response ``template`` attribute
715 715
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
716 716
 
717 717
 Django's :ref:`test client <test-client>` returns
718  
-:class:`~django.test.client.Response` objects annotated with extra testing
  718
+:class:`~django.test.Response` objects annotated with extra testing
719 719
 information. In Django versions prior to 1.3, this included a ``template``
720 720
 attribute containing information about templates rendered in generating the
721 721
 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
724 724
 to work with.
725 725
 
726 726
 In Django 1.3 the ``template`` attribute is deprecated in favor of a new
727  
-:attr:`~django.test.client.Response.templates` attribute, which is always a
  727
+:attr:`~django.test.Response.templates` attribute, which is always a
728 728
 list, even if it has only a single element or no elements.
729 729
 
730 730
 ``DjangoTestRunner``
2  docs/releases/1.4.6.txt
@@ -26,6 +26,6 @@ header and browsers seem to ignore JavaScript there.
26 26
 Bugfixes
27 27
 ========
28 28
 
29  
-* Fixed an obscure bug with the :func:`~django.test.utils.override_settings`
  29
+* Fixed an obscure bug with the :func:`~django.test.override_settings`
30 30
   decorator. If you hit an ``AttributeError: 'Settings' object has no attribute
31 31
   '_original_allowed_hosts'`` exception, it's probably fixed (#20636).
2  docs/releases/1.5.2.txt
@@ -57,6 +57,6 @@ Bugfixes
57 57
 * Ensured that the WSGI request's path is correctly based on the
58 58
   ``SCRIPT_NAME`` environment variable or the :setting:`FORCE_SCRIPT_NAME`
59 59
   setting, regardless of whether or not either has a trailing slash (#20169).
60  
-* Fixed an obscure bug with the :func:`~django.test.utils.override_settings`
  60
+* Fixed an obscure bug with the :func:`~django.test.override_settings`
61 61
   decorator. If you hit an ``AttributeError: 'Settings' object has no attribute
62 62
   '_original_allowed_hosts'`` exception, it's probably fixed (#20636).
2  docs/releases/1.6.txt
@@ -814,7 +814,7 @@ Miscellaneous
814 814
   ``{% url %}`` tag, it causes template rendering to fail like always when
815 815
   ``NoReverseMatch`` is raised.
816 816
 
817  
-* :meth:`django.test.client.Client.logout` now calls
  817
+* :meth:`django.test.Client.logout` now calls
818 818
   :meth:`django.contrib.auth.logout` which will send the
819 819
   :func:`~django.contrib.auth.signals.user_logged_out` signal.
820 820
 
3  docs/topics/auth/customizing.txt
@@ -869,8 +869,7 @@ would test three possible User models -- the default, plus the two User
869 869
 models provided by ``auth`` app::
870 870
 
871 871
     from django.contrib.auth.tests.utils import skipIfCustomUser
872  
-    from django.test import TestCase
873  
-    from django.test.utils import override_settings
  872
+    from django.test import TestCase, override_settings
874 873
 
875 874
 
876 875
     class ApplicationTestCase(TestCase):
11  docs/topics/testing/advanced.txt
@@ -5,18 +5,18 @@ Advanced testing topics
5 5
 The request factory
6 6
 ===================
7 7
 
8  
-.. module:: django.test.client
  8
+.. currentmodule:: django.test
9 9
 
10 10
 .. class:: RequestFactory
11 11
 
12  
-The :class:`~django.test.client.RequestFactory` shares the same API as
  12
+The :class:`~django.test.RequestFactory` shares the same API as
13 13
 the test client. However, instead of behaving like a browser, the
14 14
 RequestFactory provides a way to generate a request instance that can
15 15
 be used as the first argument to any view. This means you can test a
16 16
 view function the same way as you would test any other function -- as
17 17
 a black box, with exactly known inputs, testing for specific outputs.
18 18
 
19  
-The API for the :class:`~django.test.client.RequestFactory` is a slightly
  19
+The API for the :class:`~django.test.RequestFactory` is a slightly
20 20
 restricted subset of the test client API:
21 21
 
22 22
 * It only has access to the HTTP methods :meth:`~Client.get()`,
@@ -38,8 +38,7 @@ Example
38 38
 The following is a simple unit test using the request factory::
39 39
 
40 40
     from django.contrib.auth.models import User
41  
-    from django.test import TestCase
42  
-    from django.test.client import RequestFactory
  41
+    from django.test import TestCase, RequestFactory
43 42
 
44 43
     class SimpleTest(TestCase):
45 44
         def setUp(self):
@@ -165,8 +164,6 @@ exception will be raised.
165 164
 Advanced features of ``TransactionTestCase``
166 165
 ============================================
167 166
 
168  
-.. currentmodule:: django.test
169  
-
170 167
 .. attribute:: TransactionTestCase.available_apps
171 168
 
172 169
     .. versionadded:: 1.6
43  docs/topics/testing/overview.txt
@@ -313,9 +313,6 @@ Django provides a small set of tools that come in handy when writing tests.
313 313
 The test client
314 314
 ---------------
315 315
 
316  
-.. module:: django.test.client
317  
-   :synopsis: Django's test client.
318  
-
319 316
 The test client is a Python class that acts as a dummy Web browser, allowing
320 317
 you to test your views and interact with your Django-powered application
321 318
 programmatically.
@@ -349,10 +346,10 @@ A comprehensive test suite should use a combination of both test types.
349 346
 Overview and a quick example
350 347
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
351 348
 
352  
-To use the test client, instantiate ``django.test.client.Client`` and retrieve
  349
+To use the test client, instantiate ``django.test.Client`` and retrieve
353 350
 Web pages::
354 351
 
355  
-    >>> from django.test.client import Client
  352
+    >>> from django.test import Client
356 353
     >>> c = Client()
357 354
     >>> response = c.post('/login/', {'username': 'john', 'password': 'smith'})
358 355
     >>> response.status_code
@@ -413,7 +410,7 @@ Note a few important things about how the test client works:
413 410
 Making requests
414 411
 ~~~~~~~~~~~~~~~
415 412
 
416  
-Use the ``django.test.client.Client`` class to make requests.
  413
+Use the ``django.test.Client`` class to make requests.
417 414
 
418 415
 .. class:: Client(enforce_csrf_checks=False, **defaults)
419 416
 
@@ -424,8 +421,8 @@ Use the ``django.test.client.Client`` class to make requests.
424 421
         >>> c = Client(HTTP_USER_AGENT='Mozilla/5.0')
425 422
 
426 423
     The values from the ``extra`` keywords arguments passed to
427  
-    :meth:`~django.test.client.Client.get()`,
428  
-    :meth:`~django.test.client.Client.post()`, etc. have precedence over
  424
+    :meth:`~django.test.Client.get()`,
  425
+    :meth:`~django.test.Client.post()`, etc. have precedence over
429 426
     the defaults passed to the class constructor.
430 427
 
431 428
     The ``enforce_csrf_checks`` argument can be used to test CSRF
@@ -778,7 +775,7 @@ Example
778 775
 The following is a simple unit test using the test client::
779 776
 
780 777
     import unittest
781  
-    from django.test.client import Client
  778
+    from django.test import Client
782 779
 
783 780
     class SimpleTest(unittest.TestCase):
784 781
         def setUp(self):
@@ -797,15 +794,13 @@ The following is a simple unit test using the test client::
797 794
 
798 795
 .. seealso::
799 796
 
800  
-    :class:`django.test.client.RequestFactory`
  797
+    :class:`django.test.RequestFactory`
801 798
 
802 799
 .. _django-testcase-subclasses:
803 800
 
804 801
 Provided test case classes
805 802
 --------------------------
806 803
 
807  
-.. currentmodule:: django.test
808  
-
809 804
 Normal Python unit test classes extend a base class of
810 805
 :class:`unittest.TestCase`. Django provides a few extensions of this base class:
811 806
 
@@ -847,7 +842,7 @@ functionality like:
847 842
     for equality.
848 843
 
849 844
 * The ability to run tests with :ref:`modified settings <overriding-settings>`.
850  
-* Using the :attr:`~SimpleTestCase.client` :class:`~django.test.client.Client`.
  845
+* Using the :attr:`~SimpleTestCase.client` :class:`~django.test.Client`.
851 846
 * Custom test-time :attr:`URL maps <SimpleTestCase.urls>`.
852 847
 
853 848
 .. versionchanged:: 1.6
@@ -1111,7 +1106,7 @@ worry about state (such as cookies) carrying over from one test to another.
1111 1106
 This means, instead of instantiating a ``Client`` in each test::
1112 1107
 
1113 1108
     import unittest
1114  
-    from django.test.client import Client
  1109
+    from django.test import Client
1115 1110
 
1116 1111
     class SimpleTest(unittest.TestCase):
1117 1112
         def test_details(self):
@@ -1146,8 +1141,7 @@ If you want to use a different ``Client`` class (for example, a subclass
1146 1141
 with customized behavior), use the :attr:`~SimpleTestCase.client_class` class
1147 1142
 attribute::
1148 1143
 
1149  
-    from django.test import TestCase
1150  
-    from django.test.client import Client
  1144
+    from django.test import TestCase, Client
1151 1145
 
1152 1146
     class MyTestClient(Client):
1153 1147
         # Specialized methods for your environment...
@@ -1330,17 +1324,14 @@ Django provides a standard Python context manager (see :pep:`343`)
1330 1324
 This example will override the :setting:`LOGIN_URL` setting for the code
1331 1325
 in the ``with`` block and reset its value to the previous state afterwards.
1332 1326
 
1333  
-.. currentmodule:: django.test.utils
1334  
-
1335 1327
 .. function:: override_settings
1336 1328
 
1337 1329
 In case you want to override a setting for just one test method or even the
1338 1330
 whole :class:`~django.test.TestCase` class, Django provides the
1339  
-:func:`~django.test.utils.override_settings` decorator (see :pep:`318`). It's
  1331
+:func:`~django.test.override_settings` decorator (see :pep:`318`). It's
1340 1332
 used like this::
1341 1333
 
1342  
-    from django.test import TestCase
1343  
-    from django.test.utils import override_settings
  1334
+    from django.test import TestCase, override_settings
1344 1335
 
1345 1336
     class LoginTestCase(TestCase):
1346 1337
 
@@ -1351,8 +1342,7 @@ used like this::
1351 1342
 
1352 1343
 The decorator can also be applied to test case classes::
1353 1344
 
1354  
-    from django.test import TestCase
1355  
-    from django.test.utils import override_settings
  1345
+    from django.test import TestCase, override_settings
1356 1346
 
1357 1347
     @override_settings(LOGIN_URL='/other/login/')
1358 1348
     class LoginTestCase(TestCase):
@@ -1361,6 +1351,11 @@ The decorator can also be applied to test case classes::
1361 1351
             response = self.client.get('/sekrit/')
1362 1352
             self.assertRedirects(response, '/other/login/?next=/sekrit/')
1363 1353
 
  1354
+.. versionchanged:: 1.7
  1355
+
  1356
+    Previously, ``override_settings`` was imported from
  1357
+    ``django.test.utils``.
  1358
+
1364 1359
 .. note::
1365 1360
 
1366 1361
     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.
1427 1422
 Assertions
1428 1423
 ~~~~~~~~~~
1429 1424
 
1430  
-.. currentmodule:: django.test
1431  
-
1432 1425
 As Python's normal :class:`unittest.TestCase` class implements assertion methods
1433 1426
 such as :meth:`~unittest.TestCase.assertTrue` and
1434 1427
 :meth:`~unittest.TestCase.assertEqual`, Django's custom :class:`TestCase` class
3  tests/aggregation/tests.py
@@ -6,7 +6,8 @@
6 6
 
7 7
 from django.db import connection
8 8
 from django.db.models import Avg, Sum, Count, Max, Min
9  
-from django.test import TestCase, Approximate
  9
+from django.test import TestCase
  10
+from django.test.utils import Approximate
10 11
 from django.test.utils import CaptureQueriesContext
11 12
 
12 13
 from .models import Author, Publisher, Book, Store
3  tests/aggregation_regress/tests.py
@@ -8,7 +8,8 @@
8 8
 from django.core.exceptions import FieldError
9 9
 from django.contrib.contenttypes.models import ContentType
10 10
 from django.db.models import Count, Max, Avg, Sum, StdDev, Variance, F, Q
11  
-from django.test import TestCase, Approximate, skipUnlessDBFeature
  11
+from django.test import TestCase, skipUnlessDBFeature
  12
+from django.test.utils import Approximate
12 13
 from django.utils import six
13 14
 
14 15
 from .models import (Author, Book, Publisher, Clues, Entries, HardbackBook,
3  tests/expressions_regress/tests.py
@@ -7,7 +7,8 @@
7 7
 
8 8
 from django.db import connection
9 9
 from django.db.models import F
10  
-from django.test import TestCase, Approximate, skipUnlessDBFeature
  10
+from django.test import TestCase, skipUnlessDBFeature
  11
+from django.test.utils import Approximate
11 12
 
12 13
 from .models import Number, Experiment
13 14
 
3  tests/serializers/tests.py
@@ -17,7 +17,8 @@
17 17
 from django.conf import settings
18 18
 from django.core import management, serializers
19 19
 from django.db import transaction, connection
20  
-from django.test import TestCase, TransactionTestCase, Approximate
  20
+from django.test import TestCase, TransactionTestCase
  21
+from django.test.utils import Approximate
21 22
 from django.utils import six
22 23
 from django.utils.six import StringIO
23 24
 

0 notes on commit 9d70032

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