innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

Fixed ReST error in docs/testing.txt 

git-svn-id: http://code.djangoproject.com/svn/django/trunk@4507 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Adrian Holovaty 2007-02-14 23:45:45 +00:00
parent 0518205308
commit 26058b98a6
1 changed files with 59 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

117
docs/testing.txt
View File

@ -92,7 +92,7 @@ Writing unittests
Like doctests, Django's unit tests use a standard library module: unittest_. Like doctests, Django's unit tests use a standard library module: unittest_.
As with doctests, Django's test runner looks for any unit test cases defined As with doctests, Django's test runner looks for any unit test cases defined
in ``models.py``, or in a ``tests.py`` file stored in the application in ``models.py``, or in a ``tests.py`` file stored in the application
directory. directory.
An equivalent unittest test case for the above example would look like:: An equivalent unittest test case for the above example would look like::
@ -111,8 +111,8 @@ An equivalent unittest test case for the above example would look like::
self.assertEquals(self.cat.speak(), 'The cat says "meow"') self.assertEquals(self.cat.speak(), 'The cat says "meow"')
When you `run your tests`_, the test utility will find all the test cases When you `run your tests`_, the test utility will find all the test cases
(that is, subclasses of ``unittest.TestCase``) in ``models.py`` and (that is, subclasses of ``unittest.TestCase``) in ``models.py`` and
``tests.py``, automatically build a test suite out of those test cases, ``tests.py``, automatically build a test suite out of those test cases,
and run that suite. and run that suite.
For more details about ``unittest``, see the `standard library unittest For more details about ``unittest``, see the `standard library unittest
@ -164,12 +164,12 @@ in different circumstances.
Testing Tools Testing Tools
============= =============
To assist in testing various features of your application, Django provides To assist in testing various features of your application, Django provides
tools that can be used to establish tests and test conditions. tools that can be used to establish tests and test conditions.
* `Test Client`_ * `Test Client`_
* Fixtures_ * Fixtures_
Test Client Test Client
----------- -----------
@ -178,23 +178,23 @@ GET and POST requests on a URL, and observe the response that is received.
This allows you to test that the correct view is executed for a given URL, This allows you to test that the correct view is executed for a given URL,
and that the view constructs the correct response. and that the view constructs the correct response.
As the response is generated, the Test Client gathers details on the As the response is generated, the Test Client gathers details on the
Template and Context objects that were used to generate the response. These Template and Context objects that were used to generate the response. These
Templates and Contexts are then provided as part of the response, and can be Templates and Contexts are then provided as part of the response, and can be
used as test conditions. used as test conditions.
.. admonition:: Test Client vs Browser Automation? .. admonition:: Test Client vs Browser Automation?
The Test Client is not intended as a replacement for Twill_, Selenium_, The Test Client is not intended as a replacement for Twill_, Selenium_,
or other browser automation frameworks - it is intended to allow or other browser automation frameworks - it is intended to allow
testing of the contexts and templates produced by a view, testing of the contexts and templates produced by a view,
rather than the HTML rendered to the end-user. rather than the HTML rendered to the end-user.
A comprehensive test suite should use a combination of both: Test Client A comprehensive test suite should use a combination of both: Test Client
tests to establish that the correct view is being called and that tests to establish that the correct view is being called and that
the view is collecting the correct context data, and Browser Automation the view is collecting the correct context data, and Browser Automation
tests to check that user interface behaves as expected. tests to check that user interface behaves as expected.
.. _Twill: http://twill.idyll.org/ .. _Twill: http://twill.idyll.org/
.. _Selenium: http://www.openqa.org/selenium/ .. _Selenium: http://www.openqa.org/selenium/
@ -202,7 +202,7 @@ used as test conditions.
Making requests Making requests
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
Creating an instance of ``Client`` (``django.test.client.Client``) requires Creating an instance of ``Client`` (``django.test.client.Client``) requires
no arguments at time of construction. Once constructed, the following methods no arguments at time of construction. Once constructed, the following methods
can be invoked on the ``Client`` instance. can be invoked on the ``Client`` instance.
@ -220,11 +220,11 @@ can be invoked on the ``Client`` instance.
``post(path, data={})`` ``post(path, data={})``
Make a POST request on the provided ``path``. The key-value pairs in the Make a POST request on the provided ``path``. The key-value pairs in the
data dictionary will be used to create the POST data payload. This payload data dictionary will be used to create the POST data payload. This payload
will be transmitted with the mimetype ``multipart/form-data``. will be transmitted with the mimetype ``multipart/form-data``.
However submitting files is a special case. To POST a file, you need only However submitting files is a special case. To POST a file, you need only
provide the file field name as a key, and a file handle to the file you wish to provide the file field name as a key, and a file handle to the file you wish to
upload as a value. The Test Client will populate the two POST fields (i.e., upload as a value. The Test Client will populate the two POST fields (i.e.,
``field`` and ``field_file``) required by FileField. For example:: ``field`` and ``field_file``) required by FileField. For example::
c = Client() c = Client()
@ -232,8 +232,8 @@ can be invoked on the ``Client`` instance.
c.post('/customers/wishes/', {'name':'fred', 'attachment':f}) c.post('/customers/wishes/', {'name':'fred', 'attachment':f})
f.close() f.close()
will result in the evaluation of a POST request on ``/customers/wishes/``, will result in the evaluation of a POST request on ``/customers/wishes/``,
with a POST dictionary that contains `name`, `attachment` (containing the with a POST dictionary that contains `name`, `attachment` (containing the
file name), and `attachment_file` (containing the file data). Note that you file name), and `attachment_file` (containing the file data). Note that you
need to manually close the file after it has been provided to the POST. need to manually close the file after it has been provided to the POST.
@ -245,48 +245,48 @@ can be invoked on the ``Client`` instance.
call to ``login()`` stimulates the series of GET and POST calls required call to ``login()`` stimulates the series of GET and POST calls required
to log a user into a @login_required protected view. to log a user into a @login_required protected view.
If login is possible, the final return value of ``login()`` is the response If login is possible, the final return value of ``login()`` is the response
that is generated by issuing a GET request on the protected URL. If login that is generated by issuing a GET request on the protected URL. If login
is not possible, ``login()`` returns False. is not possible, ``login()`` returns False.
Note that since the test suite will be executed using the test database, Note that since the test suite will be executed using the test database,
which contains no users by default. As a result, logins for your production which contains no users by default. As a result, logins for your production
site will not work. You will need to create users as part of the test suite site will not work. You will need to create users as part of the test suite
to be able to test logins to your application. to be able to test logins to your application.
Testing Responses Testing Responses
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
The ``get()``, ``post()`` and ``login()`` methods all return a Response The ``get()``, ``post()`` and ``login()`` methods all return a Response
object. This Response object has the following properties that can be used object. This Response object has the following properties that can be used
for testing purposes: for testing purposes:
=============== ========================================================== =============== ==========================================================
Property Description Property Description
=============== ========================================================== =============== ==========================================================
``status_code`` The HTTP status of the response. See RFC2616_ for a ``status_code`` The HTTP status of the response. See RFC2616_ for a
full list of HTTP status codes. full list of HTTP status codes.
``content`` The body of the response. The is the final page ``content`` The body of the response. The is the final page
content as rendered by the view, or any error message content as rendered by the view, or any error message
(such as the URL for a 302 redirect). (such as the URL for a 302 redirect).
``template`` The Template instance that was used to render the final ``template`` The Template instance that was used to render the final
content. Testing ``template.name`` can be particularly content. Testing ``template.name`` can be particularly
useful; if the template was loaded from a file, useful; if the template was loaded from a file,
``template.name`` will be the file name that was loaded. ``template.name`` will be the file name that was loaded.
If multiple templates were rendered, (e.g., if one If multiple templates were rendered, (e.g., if one
template includes another template),``template`` will template includes another template),``template`` will
be a list of Template objects, in the order in which be a list of Template objects, in the order in which
they were rendered. they were rendered.
``context`` The Context that was used to render the template that ``context`` The Context that was used to render the template that
produced the response content. produced the response content.
As with ``template``, if multiple templates were rendered As with ``template``, if multiple templates were rendered
``context`` will be a list of Context objects, stored in ``context`` will be a list of Context objects, stored in
the order in which they were rendered. the order in which they were rendered.
=============== ========================================================== =============== ==========================================================
.. _RFC2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html .. _RFC2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
@ -295,11 +295,11 @@ Exceptions
~~~~~~~~~~ ~~~~~~~~~~
If you point the Test Client at a view that raises an exception, that exception If you point the Test Client at a view that raises an exception, that exception
will be visible in the test case. You can then use a standard ``try...catch`` will be visible in the test case. You can then use a standard ``try...catch``
block, or ``unittest.TestCase.assertRaises()`` to test for exceptions. block, or ``unittest.TestCase.assertRaises()`` to test for exceptions.
The only exceptions that are not visible in a Test Case are ``Http404``, The only exceptions that are not visible in a Test Case are ``Http404``,
``PermissionDenied`` and ``SystemExit``. Django catches these exceptions ``PermissionDenied`` and ``SystemExit``. Django catches these exceptions
internally and converts them into the appropriate HTTP responses codes. internally and converts them into the appropriate HTTP responses codes.
Persistent state Persistent state
@ -307,8 +307,8 @@ Persistent state
The Test Client is stateful; if a cookie is returned as part of a response, The Test Client is stateful; if a cookie is returned as part of a response,
that cookie is provided as part of the next request issued by that Client that cookie is provided as part of the next request issued by that Client
instance. Expiry policies for these cookies are not followed; if you want instance. Expiry policies for these cookies are not followed; if you want
a cookie to expire, either delete it manually or create a new Client a cookie to expire, either delete it manually or create a new Client
instance (which will effectively delete all cookies). instance (which will effectively delete all cookies).
There are two properties of the Test Client which are used to store persistent There are two properties of the Test Client which are used to store persistent
@ -323,25 +323,26 @@ part of a test condition.
``session`` A dictionary-like object containing session information. ``session`` A dictionary-like object containing session information.
See the `session documentation`_ for full details. See the `session documentation`_ for full details.
=============== ==========================================================
.. _`session documentation`: ../sessions/ .. _`session documentation`: ../sessions/
Example Example
~~~~~~~ ~~~~~~~
The following is a simple unit test using the Test Client:: The following is a simple unit test using the Test Client::
import unittest import unittest
from django.test.client import Client from django.test.client import Client
class SimpleTest(unittest.TestCase): class SimpleTest(unittest.TestCase):
def setUp(self): def setUp(self):
# Every test needs a client # Every test needs a client
self.client = Client() self.client = Client()
def test_details(self): def test_details(self):
# Issue a GET request # Issue a GET request
response = self.client.get('/customer/details/') response = self.client.get('/customer/details/')
# Check that the respose is 200 OK # Check that the respose is 200 OK
self.failUnlessEqual(response.status_code, 200) self.failUnlessEqual(response.status_code, 200)
# Check that the rendered context contains 5 customers # Check that the rendered context contains 5 customers
@ -368,13 +369,13 @@ but you only want to run the animals unit tests, run::
When you run your tests, you'll see a bunch of text flow by as the test When you run your tests, you'll see a bunch of text flow by as the test
database is created and models are initialized. This test database is database is created and models are initialized. This test database is
created from scratch every time you run your tests. created from scratch every time you run your tests.
By default, the test database gets its name by prepending ``test_`` to By default, the test database gets its name by prepending ``test_`` to
the database name specified by the ``DATABASE_NAME`` setting; all other the database name specified by the ``DATABASE_NAME`` setting; all other
database settings will the same as they would be for the project normally. database settings will the same as they would be for the project normally.
If you wish to use a name other than the default for the test database, If you wish to use a name other than the default for the test database,
you can use the ``TEST_DATABASE_NAME`` setting to provide a name. you can use the ``TEST_DATABASE_NAME`` setting to provide a name.
Once the test database has been established, Django will run your tests. Once the test database has been established, Django will run your tests.
If everything goes well, at the end you'll see:: If everything goes well, at the end you'll see::
@ -447,7 +448,7 @@ arguments:
The module list is the list of Python modules that contain the models to be The module list is the list of Python modules that contain the models to be
tested. This is the same format returned by ``django.db.models.get_apps()`` tested. This is the same format returned by ``django.db.models.get_apps()``
Verbosity determines the amount of notification and debug information that Verbosity determines the amount of notification and debug information that
will be printed to the console; `0` is no output, `1` is normal output, will be printed to the console; `0` is no output, `1` is normal output,
and `2` is verbose output. and `2` is verbose output.
@ -458,12 +459,12 @@ To assist in the creation of your own test runner, Django provides
a number of utility methods in the ``django.test.utils`` module. a number of utility methods in the ``django.test.utils`` module.
``setup_test_environment()`` ``setup_test_environment()``
Performs any global pre-test setup, such as the installing the Performs any global pre-test setup, such as the installing the
instrumentation of the template rendering system. instrumentation of the template rendering system.
``teardown_test_environment()`` ``teardown_test_environment()``
Performs any global post-test teardown, such as removing the instrumentation Performs any global post-test teardown, such as removing the instrumentation
of the template rendering system. of the template rendering system.
``create_test_db(verbosity=1, autoclobber=False)`` ``create_test_db(verbosity=1, autoclobber=False)``
Creates a new test database, and run ``syncdb`` against it. Creates a new test database, and run ``syncdb`` against it.