Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

A few fixes for the testing documentation:

 * Removed an extra semicolon that was preventing the rendering of a Sphinx class directive for the `Client()` class.
 * Indented `Client` class's methods.
 * Added linebreaks after attribute directives of `Response` class so Sphinx rendenders them correctly.
 * Removed trailing whitespace.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@8567 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit b2c2c3a2edf1ca3b1a10f53c0323022df92d32af 1 parent 5485e0d
Gary Wilson Jr. authored August 26, 2008

Showing 1 changed file with 192 additions and 182 deletions. Show diff stats Hide diff stats

  1. 374  docs/topics/testing.txt
374  docs/topics/testing.txt
@@ -131,21 +131,20 @@ Here is an example model doctest::
131 131
         def speak(self):
132 132
             return 'The %s says "%s"' % (self.name, self.sound)
133 133
 
134  
-When you :ref:`run your tests <running-tests>`, the test runner will find this docstring, notice
135  
-that portions of it look like an interactive Python session, and execute those
136  
-lines while checking that the results match.
137  
-
138  
-In the case of model tests, note that the test runner takes care of
139  
-creating its own test database. That is, any test that accesses a
140  
-database -- by creating and saving model instances, for example --
141  
-will not affect your production database. Each doctest begins with a
142  
-"blank slate" -- a fresh database containing an empty table for each
143  
-model. (See the section on fixtures, below, for more on this.) Note
144  
-that to use this feature, the database user Django is connecting as
145  
-must have ``CREATE DATABASE`` rights.
  134
+When you :ref:`run your tests <running-tests>`, the test runner will find this
  135
+docstring, notice that portions of it look like an interactive Python session,
  136
+and execute those lines while checking that the results match.
  137
+
  138
+In the case of model tests, note that the test runner takes care of creating
  139
+its own test database. That is, any test that accesses a database -- by
  140
+creating and saving model instances, for example -- will not affect your
  141
+production database. Each doctest begins with a "blank slate" -- a fresh
  142
+database containing an empty table for each model. (See the section on
  143
+fixtures, below, for more on this.) Note that to use this feature, the database
  144
+user Django is connecting as must have ``CREATE DATABASE`` rights.
146 145
 
147 146
 For more details about how doctest works, see the `standard library
148  
-documentation for doctest`_
  147
+documentation for doctest`_.
149 148
 
150 149
 .. _doctest: http://docs.python.org/lib/module-doctest.html
151 150
 .. _standard library documentation for doctest: doctest_
@@ -182,17 +181,17 @@ in the doctest section above::
182 181
             self.assertEquals(self.lion.speak(), 'The lion says "roar"')
183 182
             self.assertEquals(self.cat.speak(), 'The cat says "meow"')
184 183
 
185  
-When you :ref:`run your tests <running-tests>`, the default behavior of the test utility is
186  
-to find all the test cases (that is, subclasses of ``unittest.TestCase``)
187  
-in ``models.py`` and ``tests.py``, automatically build a test suite out of
188  
-those test cases, and run that suite.
  184
+When you :ref:`run your tests <running-tests>`, the default behavior of the
  185
+test utility is to find all the test cases (that is, subclasses of
  186
+``unittest.TestCase``) in ``models.py`` and ``tests.py``, automatically build a
  187
+test suite out of those test cases, and run that suite.
189 188
 
190 189
 In the Django development version, there is a second way to define the test
191 190
 suite for a module: if you define a function called ``suite()`` in either
192 191
 ``models.py`` or ``tests.py``, the Django test runner will use that function
193  
-to construct the test suite for that module. This follows the
194  
-`suggested organization`_ for unit tests. See the Python documentation for
195  
-more details on how to construct a complex test suite.
  192
+to construct the test suite for that module. This follows the `suggested
  193
+organization`_ for unit tests. See the Python documentation for more details on
  194
+how to construct a complex test suite.
196 195
 
197 196
 For more details about ``unittest``, see the `standard library unittest
198 197
 documentation`_.
@@ -242,7 +241,8 @@ in different circumstances.
242 241
 Running tests
243 242
 =============
244 243
 
245  
-Once you've written tests, run them using your project's ``manage.py`` utility::
  244
+Once you've written tests, run them using your project's ``manage.py``
  245
+utility::
246 246
 
247 247
     $ ./manage.py test
248 248
 
@@ -273,18 +273,18 @@ a test case, add the name of the test method to the label::
273 273
 The test database
274 274
 -----------------
275 275
 
276  
-Tests that require a database (namely, model tests) will not use
277  
-your "real" (production) database. A separate, blank database is created
278  
-for the tests.
  276
+Tests that require a database (namely, model tests) will not use your "real"
  277
+(production) database. A separate, blank database is created for the tests.
279 278
 
280 279
 Regardless of whether the tests pass or fail, the test database is destroyed
281 280
 when all the tests have been executed.
282 281
 
283  
-By default this test database gets its name by prepending ``test_`` to the value
284  
-of the :setting:`DATABASE_NAME` setting. When using the SQLite database engine
285  
-the tests will by default use an in-memory database (i.e., the database will be
286  
-created in memory, bypassing the filesystem entirely!). If you want to use a
287  
-different database name, specify the :setting:`TEST_DATABASE_NAME` setting.
  282
+By default this test database gets its name by prepending ``test_`` to the
  283
+value of the :setting:`DATABASE_NAME` setting. When using the SQLite database
  284
+engine the tests will by default use an in-memory database (i.e., the database
  285
+will be created in memory, bypassing the filesystem entirely!). If you want to
  286
+use a different database name, specify the :setting:`TEST_DATABASE_NAME`
  287
+setting.
288 288
 
289 289
 Aside from using a separate database, the test runner will otherwise use all of
290 290
 the same database settings you have in your settings file:
@@ -466,126 +466,130 @@ Making requests
466 466
 ~~~~~~~~~~~~~~~
467 467
 
468 468
 Use the ``django.test.client.Client`` class to make requests. It requires no
469  
-arguments at time of construction::
  469
+arguments at time of construction:
470 470
 
471 471
 .. class:: Client()
472 472
 
473  
-Once you have a ``Client`` instance, you can call any of the following methods:
  473
+    Once you have a ``Client`` instance, you can call any of the following
  474
+    methods:
  475
+
  476
+    .. method:: Client.get(path, data={})
474 477
 
475  
-.. method:: Client.get(path, data={})
  478
+        Makes a GET request on the provided ``path`` and returns a ``Response``
  479
+        object, which is documented below.
476 480
 
477  
-    Makes a GET request on the provided ``path`` and returns a ``Response``
478  
-    object, which is documented below.
  481
+        The key-value pairs in the ``data`` dictionary are used to create a GET
  482
+        data payload. For example::
479 483
 
480  
-    The key-value pairs in the ``data`` dictionary are used to create a GET
481  
-    data payload. For example::
  484
+            >>> c = Client()
  485
+            >>> c.get('/customers/details/', {'name': 'fred', 'age': 7})
482 486
 
483  
-        >>> c = Client()
484  
-        >>> c.get('/customers/details/', {'name': 'fred', 'age': 7})
  487
+        ...will result in the evaluation of a GET request equivalent to::
485 488
 
486  
-    ...will result in the evaluation of a GET request equivalent to::
  489
+            /customers/details/?name=fred&age=7
487 490
 
488  
-        /customers/details/?name=fred&age=7
  491
+    .. method:: Client.post(path, data={}, content_type=MULTIPART_CONTENT)
489 492
 
490  
-.. method:: Client.post(path, data={}, content_type=MULTIPART_CONTENT)
  493
+        Makes a POST request on the provided ``path`` and returns a
  494
+        ``Response`` object, which is documented below.
491 495
 
492  
-    Makes a POST request on the provided ``path`` and returns a ``Response``
493  
-    object, which is documented below.
  496
+        The key-value pairs in the ``data`` dictionary are used to submit POST
  497
+        data. For example::
494 498
 
495  
-    The key-value pairs in the ``data`` dictionary are used to submit POST
496  
-    data. For example::
  499
+            >>> c = Client()
  500
+            >>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'})
497 501
 
498  
-        >>> c = Client()
499  
-        >>> c.post('/login/', {'name': 'fred', 'passwd': 'secret'})
  502
+        ...will result in the evaluation of a POST request to this URL::
500 503
 
501  
-    ...will result in the evaluation of a POST request to this URL::
  504
+            /login/
502 505
 
503  
-        /login/
  506
+        ...with this POST data::
504 507
 
505  
-    ...with this POST data::
  508
+            name=fred&passwd=secret
506 509
 
507  
-        name=fred&passwd=secret
  510
+        If you provide ``content_type`` (e.g., ``text/xml`` for an XML
  511
+        payload), the contents of ``data`` will be sent as-is in the POST
  512
+        request, using ``content_type`` in the HTTP ``Content-Type`` header.
508 513
 
509  
-    If you provide ``content_type`` (e.g., ``text/xml`` for an XML payload),
510  
-    the contents of ``data`` will be sent as-is in the POST request, using
511  
-    ``content_type`` in the HTTP ``Content-Type`` header.
  514
+        If you don't provide a value for ``content_type``, the values in
  515
+        ``data`` will be transmitted with a content type of
  516
+        ``multipart/form-data``. In this case, the key-value pairs in ``data``
  517
+        will be encoded as a multipart message and used to create the POST data
  518
+        payload.
512 519
 
513  
-    If you don't provide a value for ``content_type``, the values in
514  
-    ``data`` will be transmitted with a content type of ``multipart/form-data``.
515  
-    In this case, the key-value pairs in ``data`` will be encoded as a
516  
-    multipart message and used to create the POST data payload.
  520
+        To submit multiple values for a given key -- for example, to specify
  521
+        the selections for a ``<select multiple>`` -- provide the values as a
  522
+        list or tuple for the required key. For example, this value of ``data``
  523
+        would submit three selected values for the field named ``choices``::
517 524
 
518  
-    To submit multiple values for a given key -- for example, to specify
519  
-    the selections for a ``<select multiple>`` -- provide the values as a
520  
-    list or tuple for the required key. For example, this value of ``data``
521  
-    would submit three selected values for the field named ``choices``::
  525
+            {'choices': ('a', 'b', 'd')}
522 526
 
523  
-        {'choices': ('a', 'b', 'd')}
  527
+        Submitting files is a special case. To POST a file, you need only
  528
+        provide the file field name as a key, and a file handle to the file you
  529
+        wish to upload as a value. For example::
524 530
 
525  
-    Submitting files is a special case. To POST a file, you need only provide
526  
-    the file field name as a key, and a file handle to the file you wish to
527  
-    upload as a value. For example::
  531
+            >>> c = Client()
  532
+            >>> f = open('wishlist.doc')
  533
+            >>> c.post('/customers/wishes/', {'name': 'fred', 'attachment': f})
  534
+            >>> f.close()
528 535
 
529  
-        >>> c = Client()
530  
-        >>> f = open('wishlist.doc')
531  
-        >>> c.post('/customers/wishes/', {'name': 'fred', 'attachment': f})
532  
-        >>> f.close()
  536
+        (The name ``attachment`` here is not relevant; use whatever name your
  537
+        file-processing code expects.)
533 538
 
534  
-    (The name ``attachment`` here is not relevant; use whatever name your
535  
-    file-processing code expects.)
  539
+        Note that you should manually close the file after it has been provided
  540
+        to ``post()``.
536 541
 
537  
-    Note that you should manually close the file after it has been provided to
538  
-    ``post()``.
  542
+    .. method:: Client.login(**credentials)
539 543
 
540  
-.. method:: Client.login(**credentials)
  544
+        **New in Django development version**
541 545
 
542  
-    **New in Django development version**
  546
+        If your site uses Django's :ref:`authentication system<topics-auth>`
  547
+        and you deal with logging in users, you can use the test client's
  548
+        ``login()`` method to simulate the effect of a user logging into the
  549
+        site.
543 550
 
544  
-    If your site uses Django's :ref:`authentication system<topics-auth>` and you deal with
545  
-    logging in users, you can use the test client's ``login()`` method to
546  
-    simulate the effect of a user logging into the site.
  551
+        After you call this method, the test client will have all the cookies
  552
+        and session data required to pass any login-based tests that may form
  553
+        part of a view.
547 554
 
548  
-    After you call this method, the test client will have all the cookies and
549  
-    session data required to pass any login-based tests that may form part of
550  
-    a view.
  555
+        The format of the ``credentials`` argument depends on which
  556
+        :ref:`authentication backend <authentication-backends>` you're using
  557
+        (which is configured by your :setting:`AUTHENTICATION_BACKENDS`
  558
+        setting). If you're using the standard authentication backend provided
  559
+        by Django (``ModelBackend``), ``credentials`` should be the user's
  560
+        username and password, provided as keyword arguments::
551 561
 
552  
-    The format of the ``credentials`` argument depends on which
553  
-    :ref:`authentication backend <authentication-backends>` you're using (which is configured by your
554  
-    :setting:`AUTHENTICATION_BACKENDS` setting). If you're using the standard
555  
-    authentication backend provided by Django (``ModelBackend``),
556  
-    ``credentials`` should be the user's username and password, provided as
557  
-    keyword arguments::
  562
+            >>> c = Client()
  563
+            >>> c.login(username='fred', password='secret')
558 564
 
559  
-        >>> c = Client()
560  
-        >>> c.login(username='fred', password='secret')
561  
-        
562  
-        # Now you can access a view that's only available to logged-in users.
  565
+            # Now you can access a view that's only available to logged-in users.
563 566
 
564  
-    If you're using a different authentication backend, this method may require
565  
-    different credentials. It requires whichever credentials are required by
566  
-    your backend's ``authenticate()`` method.
  567
+        If you're using a different authentication backend, this method may
  568
+        require different credentials. It requires whichever credentials are
  569
+        required by your backend's ``authenticate()`` method.
567 570
 
568  
-    ``login()`` returns ``True`` if it the credentials were accepted and login
569  
-    was successful.
  571
+        ``login()`` returns ``True`` if it the credentials were accepted and
  572
+        login was successful.
570 573
 
571  
-    Finally, you'll need to remember to create user accounts before you can use
572  
-    this method. As we explained above, the test runner is executed using a
573  
-    test database, which contains no users by default. As a result, user
574  
-    accounts that are valid on your production site will not work under test
575  
-    conditions. You'll need to create users as part of the test suite -- either
576  
-    manually (using the Django model API) or with a test fixture.
  574
+        Finally, you'll need to remember to create user accounts before you can
  575
+        use this method. As we explained above, the test runner is executed
  576
+        using a test database, which contains no users by default. As a result,
  577
+        user accounts that are valid on your production site will not work
  578
+        under test conditions. You'll need to create users as part of the test
  579
+        suite -- either manually (using the Django model API) or with a test
  580
+        fixture.
577 581
 
578  
-.. method:: Client.logout()
  582
+    .. method:: Client.logout()
579 583
 
580  
-    **New in Django development version**
  584
+        **New in Django development version**
581 585
 
582  
-    If your site uses Django's :ref:`authentication system<topics-auth>`, the ``logout()``
583  
-    method can be used to simulate the effect of a user logging out of
584  
-    your site.
  586
+        If your site uses Django's :ref:`authentication system<topics-auth>`,
  587
+        the ``logout()`` method can be used to simulate the effect of a user
  588
+        logging out of your site.
585 589
 
586  
-    After you call this method, the test client will have all the cookies and
587  
-    session data cleared to defaults. Subsequent requests will appear to
588  
-    come from an AnonymousUser.
  590
+        After you call this method, the test client will have all the cookies
  591
+        and session data cleared to defaults. Subsequent requests will appear
  592
+        to come from an AnonymousUser.
589 593
 
590 594
 Testing responses
591 595
 ~~~~~~~~~~~~~~~~~
@@ -599,36 +603,42 @@ Specifically, a ``Response`` object has the following attributes:
599 603
 
600 604
 .. class:: Response()
601 605
 
602  
-.. attribute:: Response.client``       
603  
-    The test client that was used to make the request that resulted in the
604  
-    response.
  606
+    .. attribute:: client
  607
+
  608
+        The test client that was used to make the request that resulted in the
  609
+        response.
  610
+
  611
+    .. attribute:: content
  612
+
  613
+        The body of the response, as a string. This is the final page content as
  614
+        rendered by the view, or any error message.
605 615
 
606  
-.. attribute:: Response.content
607  
-    The body of the response, as a string. This is the final page content as
608  
-    rendered by the view, or any error message.
  616
+    .. attribute:: context
609 617
 
610  
-.. attribute:: Response.context
611  
-    The template ``Context`` instance that was used to render the template that
612  
-    produced the response content.
  618
+        The template ``Context`` instance that was used to render the template that
  619
+        produced the response content.
613 620
 
614  
-    If the rendered page used multiple templates, then ``context`` will be a
615  
-    list of ``Context`` objects, in the order in which they were rendered.
  621
+        If the rendered page used multiple templates, then ``context`` will be a
  622
+        list of ``Context`` objects, in the order in which they were rendered.
616 623
 
617  
-.. attribute:: Response.request``      
618  
-    The request data that stimulated the response.
  624
+    .. attribute:: request
619 625
 
620  
-.. attribute:: Response.status_code 
621  
-    The HTTP status of the response, as an integer. See RFC2616_ for a full list
622  
-    of HTTP status codes.
  626
+        The request data that stimulated the response.
623 627
 
624  
-.. attribute:: template
625  
-    The ``Template`` instance that was used to render the final content. Use
626  
-    ``template.name`` to get the template's file name, if the template was
627  
-    loaded from a file. (The name is a string such as ``'admin/index.html'``.)
628  
-    
629  
-    If the rendered page used multiple templates -- e.g., using :ref:`template
630  
-    inheritance<template-inheritance>` -- then ``template`` will be a list of ``Template`` instances,
631  
-    in the order in which they were rendered.
  628
+    .. attribute:: status_code
  629
+
  630
+        The HTTP status of the response, as an integer. See RFC2616_ for a full
  631
+        list of HTTP status codes.
  632
+
  633
+    .. attribute:: template
  634
+
  635
+        The ``Template`` instance that was used to render the final content. Use
  636
+        ``template.name`` to get the template's file name, if the template was
  637
+        loaded from a file. (The name is a string such as ``'admin/index.html'``.)
  638
+
  639
+        If the rendered page used multiple templates -- e.g., using :ref:`template
  640
+        inheritance<template-inheritance>` -- then ``template`` will be a list of
  641
+        ``Template`` instances, in the order in which they were rendered.
632 642
 
633 643
 You can also use dictionary syntax on the response object to query the value
634 644
 of any settings in the HTTP headers. For example, you could determine the
@@ -669,8 +679,8 @@ can access these properties as part of a test condition.
669 679
 
670 680
 .. attribute:: Client.session
671 681
 
672  
-    A dictionary-like object containing session information. See the :ref:`session
673  
-    documentation<topics-http-sessions>` for full details.
  682
+    A dictionary-like object containing session information. See the
  683
+    :ref:`session documentation<topics-http-sessions>` for full details.
674 684
 
675 685
 .. _Cookie module documentation: http://docs.python.org/lib/module-Cookie.html
676 686
 
@@ -772,9 +782,9 @@ A fixture is a collection of data that Django knows how to import into a
772 782
 database. For example, if your site has user accounts, you might set up a
773 783
 fixture of fake user accounts in order to populate your database during tests.
774 784
 
775  
-The most straightforward way of creating a fixture is to use the
776  
-``manage.py dumpdata`` command. This assumes you already have some data in
777  
-your database. See the :djadmin:`dumpdata documentation<dumpdata>` for more details.
  785
+The most straightforward way of creating a fixture is to use the ``manage.py
  786
+dumpdata`` command. This assumes you already have some data in your database.
  787
+See the :djadmin:`dumpdata documentation<dumpdata>` for more details.
778 788
 
779 789
 .. note::
780 790
     If you've ever run ``manage.py syncdb``, you've already used a fixture
@@ -810,12 +820,12 @@ Here's specifically what will happen:
810 820
 
811 821
     * Then, all the named fixtures are installed. In this example, Django will
812 822
       install any JSON fixture named ``mammals``, followed by any fixture named
813  
-      ``birds``. See the :djadmin:`loaddata documentation<loaddata>` for more details on defining
814  
-      and installing fixtures.
  823
+      ``birds``. See the :djadmin:`loaddata documentation<loaddata>` for more
  824
+      details on defining and installing fixtures.
815 825
 
816 826
 This flush/load procedure is repeated for each test in the test case, so you
817  
-can be certain that the outcome of a test will not be affected by
818  
-another test, or by the order of test execution.
  827
+can be certain that the outcome of a test will not be affected by another test,
  828
+or by the order of test execution.
819 829
 
820 830
 URLconf configuration
821 831
 ~~~~~~~~~~~~~~~~~~~~~
@@ -824,23 +834,23 @@ URLconf configuration
824 834
 
825 835
 .. attribute:: TestCase.urls
826 836
 
827  
-If your application provides views, you may want to include tests that
828  
-use the test client to exercise those views. However, an end user is free
829  
-to deploy the views in your application at any URL of their choosing.
830  
-This means that your tests can't rely upon the fact that your views will
831  
-be available at a particular URL.
  837
+If your application provides views, you may want to include tests that use the
  838
+test client to exercise those views. However, an end user is free to deploy the
  839
+views in your application at any URL of their choosing. This means that your
  840
+tests can't rely upon the fact that your views will be available at a
  841
+particular URL.
832 842
 
833 843
 In order to provide a reliable URL space for your test,
834 844
 ``django.test.TestCase`` provides the ability to customize the URLconf
835  
-configuration for the duration of the execution of a test suite.
836  
-If your ``TestCase`` instance defines an ``urls`` attribute, the
837  
-``TestCase`` will use the value of that attribute as the ``ROOT_URLCONF``
838  
-for the duration of that test. 
  845
+configuration for the duration of the execution of a test suite. If your
  846
+``TestCase`` instance defines an ``urls`` attribute, the ``TestCase`` will use
  847
+the value of that attribute as the ``ROOT_URLCONF`` for the duration of that
  848
+test.
839 849
 
840 850
 For example::
841 851
 
842 852
     from django.test import TestCase
843  
-    
  853
+
844 854
     class TestMyViews(TestCase):
845 855
         urls = 'myapp.test_urls'
846 856
 
@@ -867,10 +877,10 @@ Assertions
867 877
 
868 878
 **New in Django development version**
869 879
 
870  
-As Python's normal ``unittest.TestCase`` class implements assertion
871  
-methods such as ``assertTrue`` and ``assertEquals``, Django's custom
872  
-``TestCase`` class provides a number of custom assertion methods that are
873  
-useful for testing Web applications:
  880
+As Python's normal ``unittest.TestCase`` class implements assertion methods
  881
+such as ``assertTrue`` and ``assertEquals``, Django's custom ``TestCase`` class
  882
+provides a number of custom assertion methods that are useful for testing Web
  883
+applications:
874 884
 
875 885
 .. method:: TestCase.assertContains(response, text, count=None, status_code=200)
876 886
 
@@ -913,8 +923,8 @@ useful for testing Web applications:
913 923
 
914 924
 .. method:: assertRedirects(response, expected_url, status_code=302, target_status_code=200)
915 925
 
916  
-    Asserts that the response return a ``status_code`` redirect status,
917  
-    it redirected to ``expected_url`` (including any GET data), and the subsequent
  926
+    Asserts that the response return a ``status_code`` redirect status, it
  927
+    redirected to ``expected_url`` (including any GET data), and the subsequent
918 928
     page was received with ``target_status_code``.
919 929
 
920 930
 E-mail services
@@ -930,21 +940,22 @@ test every aspect of sending e-mail -- from the number of messages sent to the
930 940
 contents of each message -- without actually sending the messages.
931 941
 
932 942
 The test runner accomplishes this by transparently replacing the normal
933  
-:class:`~django.core.mail.SMTPConnection` class with a different version. (Don't
934  
-worry -- this has no effect on any other e-mail senders outside of Django, such
935  
-as your machine's mail server, if you're running one.)
  943
+:class:`~django.core.mail.SMTPConnection` class with a different version.
  944
+(Don't worry -- this has no effect on any other e-mail senders outside of
  945
+Django, such as your machine's mail server, if you're running one.)
936 946
 
937 947
 .. currentmodule:: django.core.mail
938 948
 
939 949
 .. data:: django.core.mail.output
940 950
 
941 951
 During test running, each outgoing e-mail is saved in
942  
-``django.core.mail.outbox``. This is a simple list of all :class:`<~django.core.mail.EmailMessage>`
943  
-instances that have been sent. It does not exist under normal execution
944  
-conditions, i.e., when you're not running unit tests. The outbox is created
945  
-during test setup, along with the dummy :class:`<~django.core.mail.SMTPConnection>`. When the test
946  
-framework is torn down, the standard :class:`<~django.core.mail.SMTPConnection>` class is restored, and
947  
-the test outbox is destroyed.
  952
+``django.core.mail.outbox``. This is a simple list of all
  953
+:class:`<~django.core.mail.EmailMessage>` instances that have been sent.
  954
+It does not exist under normal execution conditions, i.e., when you're not
  955
+running unit tests. The outbox is created during test setup, along with the
  956
+dummy :class:`<~django.core.mail.SMTPConnection>`. When the test framework is
  957
+torn down, the standard :class:`<~django.core.mail.SMTPConnection>` class is
  958
+restored, and the test outbox is destroyed.
948 959
 
949 960
 Here's an example test that examines ``django.core.mail.outbox`` for length
950 961
 and contents::
@@ -965,9 +976,9 @@ and contents::
965 976
             # Verify that the subject of the first message is correct.
966 977
             self.assertEqual(mail.outbox[0].subject, 'Subject here')
967 978
 
968  
-As noted :ref:`previously <emptying-test-outbox>`, the test outbox is emptied at the start of every
969  
-test in a Django ``TestCase``. To empty the outbox manually, assign the
970  
-empty list to ``mail.outbox``::
  979
+As noted :ref:`previously <emptying-test-outbox>`, the test outbox is emptied
  980
+at the start of every test in a Django ``TestCase``. To empty the outbox
  981
+manually, assign the empty list to ``mail.outbox``::
971 982
 
972 983
     from django.core import mail
973 984
 
@@ -1004,9 +1015,9 @@ testing behavior. This behavior involves:
1004 1015
     #. Performing global post-test teardown.
1005 1016
 
1006 1017
 If you define your own test runner method and point :setting:`TEST_RUNNER` at
1007  
-that method, Django will execute your test runner whenever you run ``./manage.py
1008  
-test``. In this way, it is possible to use any test framework that can be
1009  
-executed from Python code.
  1018
+that method, Django will execute your test runner whenever you run
  1019
+``./manage.py test``. In this way, it is possible to use any test framework
  1020
+that can be executed from Python code.
1010 1021
 
1011 1022
 Defining a test runner
1012 1023
 ----------------------
@@ -1053,20 +1064,19 @@ Testing utilities
1053 1064
 .. module:: django.test.utils
1054 1065
    :synopsis: Helpers to write custom test runners.
1055 1066
 
1056  
-To assist in the creation of your own test runner, Django provides
1057  
-a number of utility methods in the ``django.test.utils`` module.
  1067
+To assist in the creation of your own test runner, Django provides a number of
  1068
+utility methods in the ``django.test.utils`` module.
1058 1069
 
1059 1070
 .. function:: setup_test_environment()
1060 1071
 
1061 1072
     Performs any global pre-test setup, such as the installing the
1062  
-    instrumentation of the template rendering system and setting up
1063  
-    the dummy ``SMTPConnection``.
  1073
+    instrumentation of the template rendering system and setting up the dummy
  1074
+    ``SMTPConnection``.
1064 1075
 
1065 1076
 .. function:: teardown_test_environment()
1066 1077
 
1067  
-    Performs any global post-test teardown, such as removing the
1068  
-    black magic hooks into the template system and restoring normal e-mail
1069  
-    services.
  1078
+    Performs any global post-test teardown, such as removing the black magic
  1079
+    hooks into the template system and restoring normal e-mail services.
1070 1080
 
1071 1081
 The creation module of the database backend (``connection.creation``) also
1072 1082
 provides some utilities that can be useful during testing.

0 notes on commit b2c2c3a

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