311
309
but not gracefully. No details of the tests run before the interruption will
312
310
be reported, and any test databases created by the run will not be destroyed.
312
Running tests outside the test runner
313
-------------------------------------
315
If you want to run tests outside of ``./manage.py test`` -- for example,
316
from a shell prompt -- you will need to set up the test
317
environment first. Django provides a convenience method to do this::
319
>>> from django.test.utils import setup_test_environment
320
>>> setup_test_environment()
322
This convenience method sets up the test database, and puts other
323
Django features into modes that allow for repeatable testing.
325
The call to :meth:`~django.test.utils.setup_test_environment` is made
326
automatically as part of the setup of `./manage.py test`. You only
327
need to manually invoke this method if you're not using running your
328
tests via Django's test runner.
314
330
The test database
315
331
-----------------
342
358
database, use the :setting:`TEST_CHARSET` option. If you're using
343
359
MySQL, you can also use the :setting:`TEST_COLLATION` option to
344
360
control the particular collation used by the test database. See the
345
:ref:`settings documentation <ref-settings>` for details of these
361
:doc:`settings documentation </ref/settings>` for details of these
346
362
advanced settings.
348
364
.. _topics-testing-masterslave:
401
417
---------------------
403
419
Regardless of the value of the :setting:`DEBUG` setting in your configuration
404
file, all Django tests run with :setting:`DEBUG=False`. This is to ensure that
420
file, all Django tests run with :setting:`DEBUG`\=False. This is to ensure that
405
421
the observed output of your code matches what will be seen in a production
556
572
This black magic (essentially a patching of Django's template system in
557
573
memory) only happens during test running.
575
* By default, the test client will disable any CSRF checks
576
performed by your site.
578
If, for some reason, you *want* the test client to perform CSRF
579
checks, you can create an instance of the test client that
580
enforces CSRF checks. To do this, pass in the
581
``enforce_csrf_checks`` argument when you construct your
584
>>> from django.test import Client
585
>>> csrf_client = Client(enforce_csrf_checks=True)
559
588
.. _urllib: http://docs.python.org/library/urllib.html
560
589
.. _urllib2: http://docs.python.org/library/urllib2.html
752
781
.. versionadded:: 1.0
754
If your site uses Django's :ref:`authentication system<topics-auth>`
783
If your site uses Django's :doc:`authentication system</topics/auth>`
755
784
and you deal with logging in users, you can use the test client's
756
785
``login()`` method to simulate the effect of a user logging into the
798
827
.. versionadded:: 1.0
800
If your site uses Django's :ref:`authentication system<topics-auth>`,
829
If your site uses Django's :doc:`authentication system</topics/auth>`,
801
830
the ``logout()`` method can be used to simulate the effect of a user
802
831
logging out of your site.
904
933
.. attribute:: Client.session
906
935
A dictionary-like object containing session information. See the
907
:ref:`session documentation<topics-http-sessions>` for full details.
936
:doc:`session documentation</topics/http/sessions>` for full details.
938
To modify the session and then save it, it must be stored in a variable
939
first (because a new ``SessionStore`` is created every time this property
942
def test_something(self):
943
session = self.client.session
944
session['somekey'] = 'test'
909
947
.. _Cookie module documentation: http://docs.python.org/library/cookie.html
1052
1090
database. For example, if your site has user accounts, you might set up a
1053
1091
fixture of fake user accounts in order to populate your database during tests.
1055
The most straightforward way of creating a fixture is to use the ``manage.py
1056
dumpdata`` command. This assumes you already have some data in your database.
1057
See the :djadmin:`dumpdata documentation<dumpdata>` for more details.
1093
The most straightforward way of creating a fixture is to use the
1094
:djadmin:`manage.py dumpdata <dumpdata>` command. This assumes you
1095
already have some data in your database. See the :djadmin:`dumpdata
1096
documentation<dumpdata>` for more details.
1060
If you've ever run ``manage.py syncdb``, you've already used a fixture
1061
without even knowing it! When you call ``syncdb`` in the database for
1062
the first time, Django installs a fixture called ``initial_data``.
1063
This gives you a way of populating a new database with any initial data,
1064
such as a default set of categories.
1099
If you've ever run :djadmin:`manage.py syncdb<syncdb>`, you've
1100
already used a fixture without even knowing it! When you call
1101
:djadmin:`syncdb` in the database for the first time, Django
1102
installs a fixture called ``initial_data``. This gives you a way
1103
of populating a new database with any initial data, such as a
1104
default set of categories.
1066
Fixtures with other names can always be installed manually using the
1067
``manage.py loaddata`` command.
1106
Fixtures with other names can always be installed manually using
1107
the :djadmin:`manage.py loaddata<loaddata>` command.
1069
1109
Once you've created a fixture and placed it in a ``fixtures`` directory in one
1070
1110
of your :setting:`INSTALLED_APPS`, you can use it in your unit tests by
1071
specifying a ``fixtures`` class attribute on your ``django.test.TestCase``
1111
specifying a ``fixtures`` class attribute on your :class:`django.test.TestCase`
1074
1114
from django.test import TestCase
1256
1296
.. versionadded:: 1.0
1258
If any of your Django views send e-mail using :ref:`Django's e-mail
1259
functionality <topics-email>`, you probably don't want to send e-mail each time
1298
If any of your Django views send e-mail using :doc:`Django's e-mail
1299
functionality </topics/email>`, you probably don't want to send e-mail each time
1260
1300
you run a test using that view. For this reason, Django's test runner
1261
1301
automatically redirects all Django-sent e-mail to a dummy outbox. This lets you
1262
1302
test every aspect of sending e-mail -- from the number of messages sent to the
added
removed
docs/topics/testing.txt
