Fixed #21027 -- Updated tutorial 5 docs to link to management shell command page.

This commit is contained in:
Max Vizard 2013-10-14 12:40:56 +01:00 committed by Tim Graham
parent 1e8eadc94e
commit 13ddf0e002
1 changed files with 10 additions and 10 deletions

View File

@ -19,8 +19,8 @@ Testing operates at different levels. Some tests might apply to a tiny detail
examine the overall operation of the software (*does a sequence of user inputs examine the overall operation of the software (*does a sequence of user inputs
on the site produce the desired result?*). That's no different from the kind of on the site produce the desired result?*). That's no different from the kind of
testing you did earlier in :doc:`Tutorial 1 </intro/tutorial01>`, using the testing you did earlier in :doc:`Tutorial 1 </intro/tutorial01>`, using the
shell to examine the behavior of a method, or running the application and :djadmin:`shell` to examine the behavior of a method, or running the
entering data to check how it behaves. application and entering data to check how it behaves.
What's different in *automated* tests is that the testing work is done for What's different in *automated* tests is that the testing work is done for
you by the system. You create a set of tests once, and then as you make changes you by the system. You create a set of tests once, and then as you make changes
@ -137,7 +137,7 @@ the ``Question``s ``pub_date`` field is in the future (which certainly isn't)
You can see this in the Admin; create a question whose date lies in the future; You can see this in the Admin; create a question whose date lies in the future;
you'll see that the ``Question`` change list claims it was published recently. you'll see that the ``Question`` change list claims it was published recently.
You can also see this using the shell:: You can also see this using the :djadmin:`shell`::
>>> import datetime >>> import datetime
>>> from django.utils import timezone >>> from django.utils import timezone
@ -153,8 +153,8 @@ Since things in the future are not 'recent', this is clearly wrong.
Create a test to expose the bug Create a test to expose the bug
------------------------------- -------------------------------
What we've just done in the shell to test for the problem is exactly what we What we've just done in the :djadmin:`shell` to test for the problem is exactly
can do in an automated test, so let's turn that into an automated test. what we can do in an automated test, so let's turn that into an automated test.
A conventional place for an application's tests is in the application's A conventional place for an application's tests is in the application's
``tests.py`` file; the testing system will automatically find tests in any file ``tests.py`` file; the testing system will automatically find tests in any file
@ -321,11 +321,11 @@ The Django test client
Django provides a test :class:`~django.test.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`` interacting with the code at the view level. We can use it in ``tests.py``
or even in the shell. or even in the :djadmin:`shell`.
We will start again with the shell, where we need to do a couple of things that We will start again with the :djadmin:`shell`, where we need to do a couple of
won't be necessary in ``tests.py``. The first is to set up the test environment things that won't be necessary in ``tests.py``. The first is to set up the test
in the shell:: environment in the :djadmin:`shell`::
>>> from django.test.utils import setup_test_environment >>> from django.test.utils import setup_test_environment
>>> setup_test_environment() >>> setup_test_environment()
@ -424,7 +424,7 @@ runserver, loading the site in your browser, creating ``Questions`` with dates
in the past and future, and checking that only those that have been published in the past and future, and checking that only those that have been published
are listed. You don't want to have to do that *every single time you make any are listed. You don't want to have to do that *every single time you make any
change that might affect this* - so let's also create a test, based on our change that might affect this* - so let's also create a test, based on our
shell session above. :djadmin:`shell` session above.
Add the following to ``polls/tests.py``:: Add the following to ``polls/tests.py``::