[1.5.x] Fixed #21027 -- Updated tutorial 5 docs to link to management shell command page.

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 </intro/tutorial01>`, 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

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

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.

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()

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``::