2012-12-15 13:03:17 +00:00
|
|
|
|
=====================================
|
|
|
|
|
Writing your first Django app, part 5
|
|
|
|
|
=====================================
|
|
|
|
|
|
|
|
|
|
This tutorial begins where :doc:`Tutorial 4 </intro/tutorial04>` left off.
|
|
|
|
|
We've built a Web-poll application, and we'll now create some automated tests
|
|
|
|
|
for it.
|
|
|
|
|
|
|
|
|
|
Introducing automated testing
|
|
|
|
|
=============================
|
|
|
|
|
|
|
|
|
|
What are automated tests?
|
|
|
|
|
-------------------------
|
|
|
|
|
|
2019-06-17 14:54:55 +00:00
|
|
|
|
Tests are routines that check the operation of your code.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
Testing operates at different levels. Some tests might apply to a tiny detail
|
2013-05-07 23:07:29 +00:00
|
|
|
|
(*does a particular model method return values as expected?*) while others
|
|
|
|
|
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
|
2015-05-11 23:43:40 +00:00
|
|
|
|
testing you did earlier in :doc:`Tutorial 2 </intro/tutorial02>`, using the
|
2013-10-14 11:40:56 +00:00
|
|
|
|
:djadmin:`shell` to examine the behavior of a method, or running the
|
|
|
|
|
application and entering data to check how it behaves.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
to your app, you can check that your code still works as you originally
|
|
|
|
|
intended, without having to perform time consuming manual testing.
|
|
|
|
|
|
|
|
|
|
Why you need to create tests
|
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
|
|
So why create tests, and why now?
|
|
|
|
|
|
|
|
|
|
You may feel that you have quite enough on your plate just learning
|
|
|
|
|
Python/Django, and having yet another thing to learn and do may seem
|
|
|
|
|
overwhelming and perhaps unnecessary. After all, our polls application is
|
|
|
|
|
working quite happily now; going through the trouble of creating automated
|
|
|
|
|
tests is not going to make it work any better. If creating the polls
|
|
|
|
|
application is the last bit of Django programming you will ever do, then true,
|
|
|
|
|
you don't need to know how to create automated tests. But, if that's not the
|
|
|
|
|
case, now is an excellent time to learn.
|
|
|
|
|
|
|
|
|
|
Tests will save you time
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Up to a certain point, 'checking that it seems to work' will be a satisfactory
|
|
|
|
|
test. In a more sophisticated application, you might have dozens of complex
|
|
|
|
|
interactions between components.
|
|
|
|
|
|
|
|
|
|
A change in any of those components could have unexpected consequences on the
|
|
|
|
|
application's behavior. Checking that it still 'seems to work' could mean
|
|
|
|
|
running through your code's functionality with twenty different variations of
|
2019-06-17 14:54:55 +00:00
|
|
|
|
your test data to make sure you haven't broken something - not a good use
|
2012-12-15 13:03:17 +00:00
|
|
|
|
of your time.
|
|
|
|
|
|
|
|
|
|
That's especially true when automated tests could do this for you in seconds.
|
|
|
|
|
If something's gone wrong, tests will also assist in identifying the code
|
|
|
|
|
that's causing the unexpected behavior.
|
|
|
|
|
|
|
|
|
|
Sometimes it may seem a chore to tear yourself away from your productive,
|
|
|
|
|
creative programming work to face the unglamorous and unexciting business
|
|
|
|
|
of writing tests, particularly when you know your code is working properly.
|
|
|
|
|
|
|
|
|
|
However, the task of writing tests is a lot more fulfilling than spending hours
|
|
|
|
|
testing your application manually or trying to identify the cause of a
|
|
|
|
|
newly-introduced problem.
|
|
|
|
|
|
|
|
|
|
Tests don't just identify problems, they prevent them
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
It's a mistake to think of tests merely as a negative aspect of development.
|
|
|
|
|
|
|
|
|
|
Without tests, the purpose or intended behavior of an application might be
|
|
|
|
|
rather opaque. Even when it's your own code, you will sometimes find yourself
|
|
|
|
|
poking around in it trying to find out what exactly it's doing.
|
|
|
|
|
|
|
|
|
|
Tests change that; they light up your code from the inside, and when something
|
|
|
|
|
goes wrong, they focus light on the part that has gone wrong - *even if you
|
|
|
|
|
hadn't even realized it had gone wrong*.
|
|
|
|
|
|
|
|
|
|
Tests make your code more attractive
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
You might have created a brilliant piece of software, but you will find that
|
2019-06-17 14:54:55 +00:00
|
|
|
|
many other developers will refuse to look at it because it lacks tests; without
|
|
|
|
|
tests, they won't trust it. Jacob Kaplan-Moss, one of Django's original
|
|
|
|
|
developers, says "Code without tests is broken by design."
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
That other developers want to see tests in your software before they take it
|
|
|
|
|
seriously is yet another reason for you to start writing tests.
|
|
|
|
|
|
|
|
|
|
Tests help teams work together
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
The previous points are written from the point of view of a single developer
|
|
|
|
|
maintaining an application. Complex applications will be maintained by teams.
|
|
|
|
|
Tests guarantee that colleagues don't inadvertently break your code (and that
|
|
|
|
|
you don't break theirs without knowing). If you want to make a living as a
|
|
|
|
|
Django programmer, you must be good at writing tests!
|
|
|
|
|
|
|
|
|
|
Basic testing strategies
|
|
|
|
|
========================
|
|
|
|
|
|
|
|
|
|
There are many ways to approach writing tests.
|
|
|
|
|
|
|
|
|
|
Some programmers follow a discipline called "`test-driven development`_"; they
|
|
|
|
|
actually write their tests before they write their code. This might seem
|
|
|
|
|
counter-intuitive, but in fact it's similar to what most people will often do
|
|
|
|
|
anyway: they describe a problem, then create some code to solve it. Test-driven
|
2019-06-17 14:54:55 +00:00
|
|
|
|
development formalizes the problem in a Python test case.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
More often, a newcomer to testing will create some code and later decide that
|
|
|
|
|
it should have some tests. Perhaps it would have been better to write some
|
|
|
|
|
tests earlier, but it's never too late to get started.
|
|
|
|
|
|
|
|
|
|
Sometimes it's difficult to figure out where to get started with writing tests.
|
|
|
|
|
If you have written several thousand lines of Python, choosing something to
|
|
|
|
|
test might not be easy. In such a case, it's fruitful to write your first test
|
|
|
|
|
the next time you make a change, either when you add a new feature or fix a bug.
|
|
|
|
|
|
|
|
|
|
So let's do that right away.
|
|
|
|
|
|
2015-08-08 10:02:32 +00:00
|
|
|
|
.. _test-driven development: https://en.wikipedia.org/wiki/Test-driven_development
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
Writing our first test
|
|
|
|
|
======================
|
|
|
|
|
|
|
|
|
|
We identify a bug
|
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
|
|
Fortunately, there's a little bug in the ``polls`` application for us to fix
|
2013-09-06 18:57:00 +00:00
|
|
|
|
right away: the ``Question.was_published_recently()`` method returns ``True`` if
|
|
|
|
|
the ``Question`` was published within the last day (which is correct) but also if
|
|
|
|
|
the ``Question``’s ``pub_date`` field is in the future (which certainly isn't).
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2018-01-29 14:25:23 +00:00
|
|
|
|
Confirm the bug by using the :djadmin:`shell` to check the method on a question
|
|
|
|
|
whose date lies in the future:
|
2018-01-11 16:23:50 +00:00
|
|
|
|
|
|
|
|
|
.. console::
|
|
|
|
|
|
|
|
|
|
$ python manage.py shell
|
|
|
|
|
|
|
|
|
|
.. code-block:: pycon
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
>>> import datetime
|
|
|
|
|
>>> from django.utils import timezone
|
2013-09-06 18:57:00 +00:00
|
|
|
|
>>> from polls.models import Question
|
|
|
|
|
>>> # create a Question instance with pub_date 30 days in the future
|
|
|
|
|
>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))
|
2012-12-15 13:03:17 +00:00
|
|
|
|
>>> # was it published recently?
|
2013-09-06 18:57:00 +00:00
|
|
|
|
>>> future_question.was_published_recently()
|
2012-12-15 13:03:17 +00:00
|
|
|
|
True
|
|
|
|
|
|
|
|
|
|
Since things in the future are not 'recent', this is clearly wrong.
|
|
|
|
|
|
|
|
|
|
Create a test to expose the bug
|
|
|
|
|
-------------------------------
|
|
|
|
|
|
2013-10-14 11:40:56 +00:00
|
|
|
|
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.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-05-11 03:08:45 +00:00
|
|
|
|
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
|
|
|
|
|
whose name begins with ``test``.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-23 22:23:47 +00:00
|
|
|
|
Put the following in the ``tests.py`` file in the ``polls`` application:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/tests.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
import datetime
|
|
|
|
|
|
|
|
|
|
from django.test import TestCase
|
2018-05-12 17:37:42 +00:00
|
|
|
|
from django.utils import timezone
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2015-02-22 14:59:56 +00:00
|
|
|
|
from .models import Question
|
|
|
|
|
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
class QuestionModelTests(TestCase):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
def test_was_published_recently_with_future_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
was_published_recently() returns False for questions whose pub_date
|
|
|
|
|
is in the future.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
time = timezone.now() + datetime.timedelta(days=30)
|
|
|
|
|
future_question = Question(pub_date=time)
|
2016-06-16 18:19:18 +00:00
|
|
|
|
self.assertIs(future_question.was_published_recently(), False)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2018-04-19 09:09:38 +00:00
|
|
|
|
Here we have created a :class:`django.test.TestCase` subclass with a method that
|
|
|
|
|
creates a ``Question`` instance with a ``pub_date`` in the future. We then check
|
|
|
|
|
the output of ``was_published_recently()`` - which *ought* to be False.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
Running tests
|
|
|
|
|
-------------
|
|
|
|
|
|
2018-01-11 16:23:50 +00:00
|
|
|
|
In the terminal, we can run our test:
|
|
|
|
|
|
|
|
|
|
.. console::
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-18 14:35:41 +00:00
|
|
|
|
$ python manage.py test polls
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
and you'll see something like::
|
|
|
|
|
|
2019-02-13 18:59:44 +00:00
|
|
|
|
Creating test database for alias 'default'...
|
2016-03-18 14:24:13 +00:00
|
|
|
|
System check identified no issues (0 silenced).
|
2012-12-15 13:03:17 +00:00
|
|
|
|
F
|
|
|
|
|
======================================================================
|
2017-06-07 13:47:15 +00:00
|
|
|
|
FAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
|
Traceback (most recent call last):
|
2013-09-06 18:57:00 +00:00
|
|
|
|
File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question
|
2016-06-16 18:19:18 +00:00
|
|
|
|
self.assertIs(future_question.was_published_recently(), False)
|
|
|
|
|
AssertionError: True is not False
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
|
Ran 1 test in 0.001s
|
|
|
|
|
|
|
|
|
|
FAILED (failures=1)
|
2019-02-13 18:59:44 +00:00
|
|
|
|
Destroying test database for alias 'default'...
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2019-09-14 02:47:15 +00:00
|
|
|
|
.. admonition:: Different error?
|
|
|
|
|
|
|
|
|
|
If instead you're getting a ``NameError`` here, you may have missed a step
|
|
|
|
|
in :ref:`Part 2 <tutorial02-import-timezone>` where we added imports of
|
|
|
|
|
``datetime`` and ``timezone`` to ``polls/models.py``. Copy the imports from
|
|
|
|
|
that section, and try running your tests again.
|
|
|
|
|
|
2012-12-15 13:03:17 +00:00
|
|
|
|
What happened is this:
|
|
|
|
|
|
2018-01-11 16:23:50 +00:00
|
|
|
|
* ``manage.py test polls`` looked for tests in the ``polls`` application
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
* it found a subclass of the :class:`django.test.TestCase` class
|
|
|
|
|
|
|
|
|
|
* it created a special database for the purpose of testing
|
|
|
|
|
|
|
|
|
|
* it looked for test methods - ones whose names begin with ``test``
|
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
* in ``test_was_published_recently_with_future_question`` it created a ``Question``
|
2012-12-15 13:03:17 +00:00
|
|
|
|
instance whose ``pub_date`` field is 30 days in the future
|
|
|
|
|
|
2016-08-19 15:10:28 +00:00
|
|
|
|
* ... and using the ``assertIs()`` method, it discovered that its
|
2012-12-15 13:03:17 +00:00
|
|
|
|
``was_published_recently()`` returns ``True``, though we wanted it to return
|
|
|
|
|
``False``
|
|
|
|
|
|
|
|
|
|
The test informs us which test failed and even the line on which the failure
|
|
|
|
|
occurred.
|
|
|
|
|
|
|
|
|
|
Fixing the bug
|
|
|
|
|
--------------
|
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
We already know what the problem is: ``Question.was_published_recently()`` should
|
2012-12-15 13:03:17 +00:00
|
|
|
|
return ``False`` if its ``pub_date`` is in the future. Amend the method in
|
|
|
|
|
``models.py``, so that it will only return ``True`` if the date is also in the
|
2013-09-23 22:23:47 +00:00
|
|
|
|
past:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/models.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
def was_published_recently(self):
|
|
|
|
|
now = timezone.now()
|
2014-06-15 10:44:33 +00:00
|
|
|
|
return now - datetime.timedelta(days=1) <= self.pub_date <= now
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
and run the test again::
|
|
|
|
|
|
2019-02-13 18:59:44 +00:00
|
|
|
|
Creating test database for alias 'default'...
|
2016-03-18 14:24:13 +00:00
|
|
|
|
System check identified no issues (0 silenced).
|
2012-12-15 13:03:17 +00:00
|
|
|
|
.
|
|
|
|
|
----------------------------------------------------------------------
|
|
|
|
|
Ran 1 test in 0.001s
|
|
|
|
|
|
|
|
|
|
OK
|
2019-02-13 18:59:44 +00:00
|
|
|
|
Destroying test database for alias 'default'...
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
After identifying a bug, we wrote a test that exposes it and corrected the bug
|
|
|
|
|
in the code so our test passes.
|
|
|
|
|
|
|
|
|
|
Many other things might go wrong with our application in the future, but we can
|
2019-06-17 14:54:55 +00:00
|
|
|
|
be sure that we won't inadvertently reintroduce this bug, because running the
|
|
|
|
|
test will warn us immediately. We can consider this little portion of the
|
|
|
|
|
application pinned down safely forever.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
More comprehensive tests
|
|
|
|
|
------------------------
|
|
|
|
|
|
|
|
|
|
While we're here, we can further pin down the ``was_published_recently()``
|
|
|
|
|
method; in fact, it would be positively embarrassing if in fixing one bug we had
|
|
|
|
|
introduced another.
|
|
|
|
|
|
|
|
|
|
Add two more test methods to the same class, to test the behavior of the method
|
2013-09-23 22:23:47 +00:00
|
|
|
|
more comprehensively:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/tests.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
def test_was_published_recently_with_old_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
was_published_recently() returns False for questions whose pub_date
|
|
|
|
|
is older than 1 day.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-07-06 22:23:49 +00:00
|
|
|
|
time = timezone.now() - datetime.timedelta(days=1, seconds=1)
|
2013-09-06 18:57:00 +00:00
|
|
|
|
old_question = Question(pub_date=time)
|
2016-06-16 18:19:18 +00:00
|
|
|
|
self.assertIs(old_question.was_published_recently(), False)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
def test_was_published_recently_with_recent_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
was_published_recently() returns True for questions whose pub_date
|
|
|
|
|
is within the last day.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-06 16:12:42 +00:00
|
|
|
|
time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)
|
2013-09-06 18:57:00 +00:00
|
|
|
|
recent_question = Question(pub_date=time)
|
2016-06-16 18:19:18 +00:00
|
|
|
|
self.assertIs(recent_question.was_published_recently(), True)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
And now we have three tests that confirm that ``Question.was_published_recently()``
|
|
|
|
|
returns sensible values for past, recent, and future questions.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2019-06-17 14:54:55 +00:00
|
|
|
|
Again, ``polls`` is a minimal application, but however complex it grows in the
|
2012-12-15 13:03:17 +00:00
|
|
|
|
future and whatever other code it interacts with, we now have some guarantee
|
|
|
|
|
that the method we have written tests for will behave in expected ways.
|
|
|
|
|
|
|
|
|
|
Test a view
|
|
|
|
|
===========
|
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
The polls application is fairly undiscriminating: it will publish any question,
|
2012-12-15 13:03:17 +00:00
|
|
|
|
including ones whose ``pub_date`` field lies in the future. We should improve
|
2013-09-06 18:57:00 +00:00
|
|
|
|
this. Setting a ``pub_date`` in the future should mean that the Question is
|
2012-12-15 13:03:17 +00:00
|
|
|
|
published at that moment, but invisible until then.
|
|
|
|
|
|
|
|
|
|
A test for a view
|
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
|
|
When we fixed the bug above, we wrote the test first and then the code to fix
|
2019-06-17 14:54:55 +00:00
|
|
|
|
it. In fact that was an example of test-driven development, but it doesn't
|
|
|
|
|
really matter in which order we do the work.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
In our first test, we focused closely on the internal behavior of the code. For
|
|
|
|
|
this test, we want to check its behavior as it would be experienced by a user
|
|
|
|
|
through a web browser.
|
|
|
|
|
|
|
|
|
|
Before we try to fix anything, let's have a look at the tools at our disposal.
|
|
|
|
|
|
|
|
|
|
The Django test client
|
|
|
|
|
----------------------
|
|
|
|
|
|
2013-09-09 08:59:47 +00:00
|
|
|
|
Django provides a test :class:`~django.test.Client` to simulate a user
|
2012-12-15 13:03:17 +00:00
|
|
|
|
interacting with the code at the view level. We can use it in ``tests.py``
|
2013-10-14 11:40:56 +00:00
|
|
|
|
or even in the :djadmin:`shell`.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-10-14 11:40:56 +00:00
|
|
|
|
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
|
2018-01-11 16:23:50 +00:00
|
|
|
|
environment in the :djadmin:`shell`:
|
|
|
|
|
|
|
|
|
|
.. console::
|
|
|
|
|
|
|
|
|
|
$ python manage.py shell
|
|
|
|
|
|
|
|
|
|
.. code-block:: pycon
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
>>> from django.test.utils import setup_test_environment
|
|
|
|
|
>>> setup_test_environment()
|
|
|
|
|
|
2013-05-06 17:55:02 +00:00
|
|
|
|
:meth:`~django.test.utils.setup_test_environment` installs a template renderer
|
|
|
|
|
which will allow us to examine some additional attributes on responses such as
|
|
|
|
|
``response.context`` that otherwise wouldn't be available. Note that this
|
|
|
|
|
method *does not* setup a test database, so the following will be run against
|
|
|
|
|
the existing database and the output may differ slightly depending on what
|
2016-08-22 23:22:04 +00:00
|
|
|
|
questions you already created. You might get unexpected results if your
|
|
|
|
|
``TIME_ZONE`` in ``settings.py`` isn't correct. If you don't remember setting
|
|
|
|
|
it earlier, check it before continuing.
|
2013-05-06 17:55:02 +00:00
|
|
|
|
|
2012-12-15 13:03:17 +00:00
|
|
|
|
Next we need to import the test client class (later in ``tests.py`` we will use
|
|
|
|
|
the :class:`django.test.TestCase` class, which comes with its own client, so
|
|
|
|
|
this won't be required)::
|
|
|
|
|
|
2013-09-09 08:59:47 +00:00
|
|
|
|
>>> from django.test import Client
|
2012-12-15 13:03:17 +00:00
|
|
|
|
>>> # create an instance of the client for our use
|
|
|
|
|
>>> client = Client()
|
|
|
|
|
|
|
|
|
|
With that ready, we can ask the client to do some work for us::
|
|
|
|
|
|
|
|
|
|
>>> # get a response from '/'
|
|
|
|
|
>>> response = client.get('/')
|
2017-05-21 23:54:26 +00:00
|
|
|
|
Not Found: /
|
2017-04-11 12:30:55 +00:00
|
|
|
|
>>> # we should expect a 404 from that address; if you instead see an
|
|
|
|
|
>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably
|
|
|
|
|
>>> # omitted the setup_test_environment() call described earlier.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
>>> response.status_code
|
|
|
|
|
404
|
|
|
|
|
>>> # on the other hand we should expect to find something at '/polls/'
|
2014-03-02 16:05:57 +00:00
|
|
|
|
>>> # we'll use 'reverse()' rather than a hardcoded URL
|
2015-12-30 15:51:16 +00:00
|
|
|
|
>>> from django.urls import reverse
|
2012-12-15 13:03:17 +00:00
|
|
|
|
>>> response = client.get(reverse('polls:index'))
|
|
|
|
|
>>> response.status_code
|
|
|
|
|
200
|
|
|
|
|
>>> response.content
|
2019-04-24 11:30:34 +00:00
|
|
|
|
b'\n <ul>\n \n <li><a href="/polls/1/">What's up?</a></li>\n \n </ul>\n\n'
|
2013-09-06 18:57:00 +00:00
|
|
|
|
>>> response.context['latest_question_list']
|
2016-08-22 23:22:04 +00:00
|
|
|
|
<QuerySet [<Question: What's up?>]>
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
Improving our view
|
|
|
|
|
------------------
|
|
|
|
|
|
|
|
|
|
The list of polls shows polls that aren't published yet (i.e. those that have a
|
|
|
|
|
``pub_date`` in the future). Let's fix that.
|
|
|
|
|
|
2015-05-11 23:43:40 +00:00
|
|
|
|
In :doc:`Tutorial 4 </intro/tutorial04>` we introduced a class-based view,
|
2013-09-23 22:23:47 +00:00
|
|
|
|
based on :class:`~django.views.generic.list.ListView`:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/views.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-05-11 23:08:57 +00:00
|
|
|
|
class IndexView(generic.ListView):
|
|
|
|
|
template_name = 'polls/index.html'
|
2013-09-06 18:57:00 +00:00
|
|
|
|
context_object_name = 'latest_question_list'
|
2013-05-11 23:08:57 +00:00
|
|
|
|
|
|
|
|
|
def get_queryset(self):
|
2013-09-06 18:57:00 +00:00
|
|
|
|
"""Return the last five published questions."""
|
|
|
|
|
return Question.objects.order_by('-pub_date')[:5]
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2015-07-08 19:11:40 +00:00
|
|
|
|
We need to amend the ``get_queryset()`` method and change it so that it also
|
2013-05-11 23:08:57 +00:00
|
|
|
|
checks the date by comparing it with ``timezone.now()``. First we need to add
|
2013-09-23 22:23:47 +00:00
|
|
|
|
an import:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/views.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
from django.utils import timezone
|
|
|
|
|
|
2013-09-23 22:23:47 +00:00
|
|
|
|
and then we must amend the ``get_queryset`` method like so:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/views.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-05-11 23:08:57 +00:00
|
|
|
|
def get_queryset(self):
|
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
Return the last five published questions (not including those set to be
|
2013-05-11 23:08:57 +00:00
|
|
|
|
published in the future).
|
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
return Question.objects.filter(
|
2013-05-11 23:08:57 +00:00
|
|
|
|
pub_date__lte=timezone.now()
|
|
|
|
|
).order_by('-pub_date')[:5]
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
``Question.objects.filter(pub_date__lte=timezone.now())`` returns a queryset
|
|
|
|
|
containing ``Question``\s whose ``pub_date`` is less than or equal to - that
|
|
|
|
|
is, earlier than or equal to - ``timezone.now``.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
Testing our new view
|
|
|
|
|
--------------------
|
|
|
|
|
|
2018-07-31 15:32:38 +00:00
|
|
|
|
Now you can satisfy yourself that this behaves as expected by firing up
|
|
|
|
|
``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 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 :djadmin:`shell` session above.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-23 22:23:47 +00:00
|
|
|
|
Add the following to ``polls/tests.py``:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/tests.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2015-12-30 15:51:16 +00:00
|
|
|
|
from django.urls import reverse
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2014-03-09 21:07:39 +00:00
|
|
|
|
and we'll create a shortcut function to create questions as well as a new test
|
2013-09-23 22:23:47 +00:00
|
|
|
|
class:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/tests.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
def create_question(question_text, days):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
Create a question with the given `question_text` and published the
|
2015-12-07 09:05:47 +00:00
|
|
|
|
given number of `days` offset to now (negative for questions published
|
2013-09-06 18:57:00 +00:00
|
|
|
|
in the past, positive for questions that have yet to be published).
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
time = timezone.now() + datetime.timedelta(days=days)
|
2016-06-02 19:56:13 +00:00
|
|
|
|
return Question.objects.create(question_text=question_text, pub_date=time)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
class QuestionIndexViewTests(TestCase):
|
|
|
|
|
def test_no_questions(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
If no questions exist, an appropriate message is displayed.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
|
|
|
|
response = self.client.get(reverse('polls:index'))
|
|
|
|
|
self.assertEqual(response.status_code, 200)
|
|
|
|
|
self.assertContains(response, "No polls are available.")
|
2013-09-06 18:57:00 +00:00
|
|
|
|
self.assertQuerysetEqual(response.context['latest_question_list'], [])
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
def test_past_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
Questions with a pub_date in the past are displayed on the
|
2015-03-15 14:51:24 +00:00
|
|
|
|
index page.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
create_question(question_text="Past question.", days=-30)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
response = self.client.get(reverse('polls:index'))
|
|
|
|
|
self.assertQuerysetEqual(
|
2013-09-06 18:57:00 +00:00
|
|
|
|
response.context['latest_question_list'],
|
|
|
|
|
['<Question: Past question.>']
|
2012-12-15 13:03:17 +00:00
|
|
|
|
)
|
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
def test_future_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
Questions with a pub_date in the future aren't displayed on
|
2013-09-06 18:57:00 +00:00
|
|
|
|
the index page.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
create_question(question_text="Future question.", days=30)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
response = self.client.get(reverse('polls:index'))
|
2016-06-02 19:56:13 +00:00
|
|
|
|
self.assertContains(response, "No polls are available.")
|
2013-09-06 18:57:00 +00:00
|
|
|
|
self.assertQuerysetEqual(response.context['latest_question_list'], [])
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
def test_future_question_and_past_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
Even if both past and future questions exist, only past questions
|
2017-06-07 13:47:15 +00:00
|
|
|
|
are displayed.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
create_question(question_text="Past question.", days=-30)
|
|
|
|
|
create_question(question_text="Future question.", days=30)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
response = self.client.get(reverse('polls:index'))
|
|
|
|
|
self.assertQuerysetEqual(
|
2013-09-06 18:57:00 +00:00
|
|
|
|
response.context['latest_question_list'],
|
|
|
|
|
['<Question: Past question.>']
|
2012-12-15 13:03:17 +00:00
|
|
|
|
)
|
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
def test_two_past_questions(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
The questions index page may display multiple questions.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2013-09-10 13:54:26 +00:00
|
|
|
|
create_question(question_text="Past question 1.", days=-30)
|
2013-09-06 18:57:00 +00:00
|
|
|
|
create_question(question_text="Past question 2.", days=-5)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
response = self.client.get(reverse('polls:index'))
|
|
|
|
|
self.assertQuerysetEqual(
|
2013-09-06 18:57:00 +00:00
|
|
|
|
response.context['latest_question_list'],
|
|
|
|
|
['<Question: Past question 2.>', '<Question: Past question 1.>']
|
2012-12-15 13:03:17 +00:00
|
|
|
|
)
|
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
|
2012-12-15 13:03:17 +00:00
|
|
|
|
Let's look at some of these more closely.
|
|
|
|
|
|
2014-03-09 21:07:39 +00:00
|
|
|
|
First is a question shortcut function, ``create_question``, to take some
|
2013-09-06 18:57:00 +00:00
|
|
|
|
repetition out of the process of creating questions.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
``test_no_questions`` doesn't create any questions, but checks the message:
|
|
|
|
|
"No polls are available." and verifies the ``latest_question_list`` is empty.
|
|
|
|
|
Note that the :class:`django.test.TestCase` class provides some additional
|
|
|
|
|
assertion methods. In these examples, we use
|
2013-05-18 22:04:34 +00:00
|
|
|
|
:meth:`~django.test.SimpleTestCase.assertContains()` and
|
|
|
|
|
:meth:`~django.test.TransactionTestCase.assertQuerysetEqual()`.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
In ``test_past_question``, we create a question and verify that it appears in
|
|
|
|
|
the list.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
In ``test_future_question``, we create a question with a ``pub_date`` in the
|
|
|
|
|
future. The database is reset for each test method, so the first question is no
|
|
|
|
|
longer there, and so again the index shouldn't have any questions in it.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
And so on. In effect, we are using the tests to tell a story of admin input
|
|
|
|
|
and user experience on the site, and checking that at every state and for every
|
|
|
|
|
new change in the state of the system, the expected results are published.
|
|
|
|
|
|
|
|
|
|
Testing the ``DetailView``
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
What we have works well; however, even though future questions don't appear in
|
|
|
|
|
the *index*, users can still reach them if they know or guess the right URL. So
|
2013-09-23 22:23:47 +00:00
|
|
|
|
we need to add a similar constraint to ``DetailView``:
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/views.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-05-11 23:08:57 +00:00
|
|
|
|
class DetailView(generic.DetailView):
|
|
|
|
|
...
|
|
|
|
|
def get_queryset(self):
|
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
Excludes any questions that aren't published yet.
|
2013-05-11 23:08:57 +00:00
|
|
|
|
"""
|
2013-09-06 18:57:00 +00:00
|
|
|
|
return Question.objects.filter(pub_date__lte=timezone.now())
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-09-06 18:57:00 +00:00
|
|
|
|
And of course, we will add some tests, to check that a ``Question`` whose
|
2012-12-15 13:03:17 +00:00
|
|
|
|
``pub_date`` is in the past can be displayed, and that one with a ``pub_date``
|
2013-09-23 22:23:47 +00:00
|
|
|
|
in the future is not:
|
|
|
|
|
|
2018-09-10 17:00:34 +00:00
|
|
|
|
.. code-block:: python
|
|
|
|
|
:caption: polls/tests.py
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
class QuestionDetailViewTests(TestCase):
|
|
|
|
|
def test_future_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
The detail view of a question with a pub_date in the future
|
|
|
|
|
returns a 404 not found.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2016-06-02 19:56:13 +00:00
|
|
|
|
future_question = create_question(question_text='Future question.', days=5)
|
|
|
|
|
url = reverse('polls:detail', args=(future_question.id,))
|
|
|
|
|
response = self.client.get(url)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
self.assertEqual(response.status_code, 404)
|
|
|
|
|
|
2017-06-07 13:47:15 +00:00
|
|
|
|
def test_past_question(self):
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2017-06-07 13:47:15 +00:00
|
|
|
|
The detail view of a question with a pub_date in the past
|
|
|
|
|
displays the question's text.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
"""
|
2016-06-02 19:56:13 +00:00
|
|
|
|
past_question = create_question(question_text='Past Question.', days=-5)
|
|
|
|
|
url = reverse('polls:detail', args=(past_question.id,))
|
|
|
|
|
response = self.client.get(url)
|
|
|
|
|
self.assertContains(response, past_question.question_text)
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
Ideas for more tests
|
|
|
|
|
--------------------
|
|
|
|
|
|
2013-05-11 23:08:57 +00:00
|
|
|
|
We ought to add a similar ``get_queryset`` method to ``ResultsView`` and
|
|
|
|
|
create a new test class for that view. It'll be very similar to what we have
|
|
|
|
|
just created; in fact there will be a lot of repetition.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
We could also improve our application in other ways, adding tests along the
|
2013-09-06 18:57:00 +00:00
|
|
|
|
way. For example, it's silly that ``Questions`` can be published on the site
|
|
|
|
|
that have no ``Choices``. So, our views could check for this, and exclude such
|
|
|
|
|
``Questions``. Our tests would create a ``Question`` without ``Choices`` and
|
|
|
|
|
then test that it's not published, as well as create a similar ``Question``
|
|
|
|
|
*with* ``Choices``, and test that it *is* published.
|
|
|
|
|
|
|
|
|
|
Perhaps logged-in admin users should be allowed to see unpublished
|
|
|
|
|
``Questions``, but not ordinary visitors. Again: whatever needs to be added to
|
|
|
|
|
the software to accomplish this should be accompanied by a test, whether you
|
|
|
|
|
write the test first and then make the code pass the test, or work out the
|
|
|
|
|
logic in your code first and then write a test to prove it.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
At a certain point you are bound to look at your tests and wonder whether your
|
|
|
|
|
code is suffering from test bloat, which brings us to:
|
|
|
|
|
|
|
|
|
|
When testing, more is better
|
|
|
|
|
============================
|
|
|
|
|
|
|
|
|
|
It might seem that our tests are growing out of control. At this rate there will
|
|
|
|
|
soon be more code in our tests than in our application, and the repetition
|
|
|
|
|
is unaesthetic, compared to the elegant conciseness of the rest of our code.
|
|
|
|
|
|
|
|
|
|
**It doesn't matter**. Let them grow. For the most part, you can write a test
|
|
|
|
|
once and then forget about it. It will continue performing its useful function
|
|
|
|
|
as you continue to develop your program.
|
|
|
|
|
|
|
|
|
|
Sometimes tests will need to be updated. Suppose that we amend our views so that
|
2013-09-06 18:57:00 +00:00
|
|
|
|
only ``Questions`` with ``Choices`` are published. In that case, many of our
|
2012-12-15 13:03:17 +00:00
|
|
|
|
existing tests will fail - *telling us exactly which tests need to be amended to
|
|
|
|
|
bring them up to date*, so to that extent tests help look after themselves.
|
|
|
|
|
|
|
|
|
|
At worst, as you continue developing, you might find that you have some tests
|
|
|
|
|
that are now redundant. Even that's not a problem; in testing redundancy is
|
|
|
|
|
a *good* thing.
|
|
|
|
|
|
|
|
|
|
As long as your tests are sensibly arranged, they won't become unmanageable.
|
|
|
|
|
Good rules-of-thumb include having:
|
|
|
|
|
|
|
|
|
|
* a separate ``TestClass`` for each model or view
|
|
|
|
|
* a separate test method for each set of conditions you want to test
|
|
|
|
|
* test method names that describe their function
|
|
|
|
|
|
|
|
|
|
Further testing
|
|
|
|
|
===============
|
|
|
|
|
|
|
|
|
|
This tutorial only introduces some of the basics of testing. There's a great
|
|
|
|
|
deal more you can do, and a number of very useful tools at your disposal to
|
|
|
|
|
achieve some very clever things.
|
|
|
|
|
|
|
|
|
|
For example, while our tests here have covered some of the internal logic of a
|
|
|
|
|
model and the way our views publish information, you can use an "in-browser"
|
|
|
|
|
framework such as Selenium_ to test the way your HTML actually renders in a
|
|
|
|
|
browser. These tools allow you to check not just the behavior of your Django
|
|
|
|
|
code, but also, for example, of your JavaScript. It's quite something to see
|
|
|
|
|
the tests launch a browser, and start interacting with your site, as if a human
|
|
|
|
|
being were driving it! Django includes :class:`~django.test.LiveServerTestCase`
|
|
|
|
|
to facilitate integration with tools like Selenium.
|
|
|
|
|
|
|
|
|
|
If you have a complex application, you may want to run tests automatically
|
|
|
|
|
with every commit for the purposes of `continuous integration`_, so that
|
|
|
|
|
quality control is itself - at least partially - automated.
|
|
|
|
|
|
|
|
|
|
A good way to spot untested parts of your application is to check code
|
|
|
|
|
coverage. This also helps identify fragile or even dead code. If you can't test
|
|
|
|
|
a piece of code, it usually means that code should be refactored or removed.
|
|
|
|
|
Coverage will help to identify dead code. See
|
|
|
|
|
:ref:`topics-testing-code-coverage` for details.
|
|
|
|
|
|
2013-12-13 15:58:49 +00:00
|
|
|
|
:doc:`Testing in Django </topics/testing/index>` has comprehensive
|
2012-12-15 13:03:17 +00:00
|
|
|
|
information about testing.
|
|
|
|
|
|
|
|
|
|
.. _Selenium: http://seleniumhq.org/
|
2015-08-08 10:02:32 +00:00
|
|
|
|
.. _continuous integration: https://en.wikipedia.org/wiki/Continuous_integration
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
|
|
|
|
What's next?
|
|
|
|
|
============
|
|
|
|
|
|
2013-03-04 11:05:11 +00:00
|
|
|
|
For full details on testing, see :doc:`Testing in Django
|
|
|
|
|
</topics/testing/index>`.
|
2012-12-15 13:03:17 +00:00
|
|
|
|
|
2013-03-04 11:05:11 +00:00
|
|
|
|
When you're comfortable with testing Django views, read
|
|
|
|
|
:doc:`part 6 of this tutorial</intro/tutorial06>` to learn about
|
|
|
|
|
static files management.
|