From e532d1e38f30689f6483ee5fd580eaf8d08a6b1e Mon Sep 17 00:00:00 2001 From: Max Vizard Date: Mon, 14 Oct 2013 12:40:56 +0100 Subject: [PATCH] [1.5.x] Fixed #21027 -- Updated tutorial 5 docs to link to management shell command page. Backport of 13ddf0e002 from master --- docs/intro/tutorial05.txt | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/intro/tutorial05.txt b/docs/intro/tutorial05.txt index 60a8996ec49..23c9856bed1 100644 --- a/docs/intro/tutorial05.txt +++ b/docs/intro/tutorial05.txt @@ -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 on the site produce the desired result?* That's no different from the kind of testing you did earlier in :doc:`Tutorial 1 `, using the -shell to examine the behavior of a method, or running the application and -entering data to check how it behaves. +:djadmin:`shell` to examine the behavior of a method, or running the +application and entering data to check how it behaves. 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 @@ -137,7 +137,7 @@ the ``Poll``'s ``pub_date`` field is in the future (which certainly isn't). You can see this in the Admin; create a poll whose date lies in the future; you'll see that the ``Poll`` 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 >>> 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 ------------------------------- -What we've just done in the shell to test for the problem is exactly what we -can do in an automated test, so let's turn that into an automated test. +What we've just done in the :djadmin:`shell` to test for the problem is exactly +what we can do in an automated test, so let's turn that into an automated test. The best place for an application's tests is in the application's ``tests.py`` file - the testing system will look there for tests automatically. @@ -318,11 +318,11 @@ The Django test client Django provides a test :class:`~django.test.client.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. +or even in the :djadmin:`shell`. -We will start again with the shell, where we need to do a couple of things that -won't be necessary in ``tests.py``. The first is to set up the test environment -in the shell:: +We will start again with the :djadmin:`shell`, where we need to do a couple of +things that won't be necessary in ``tests.py``. The first is to set up the test +environment in the :djadmin:`shell`:: >>> from django.test.utils import setup_test_environment >>> setup_test_environment() @@ -421,7 +421,7 @@ runserver, loading the site in your browser, creating ``Polls`` with dates 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 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``::