<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Writing and running tests — Django 1.6.7 documentation</title>
<link rel="stylesheet" href="../../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../../',
VERSION: '1.6.7',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../../_static/jquery.js"></script>
<script type="text/javascript" src="../../_static/underscore.js"></script>
<script type="text/javascript" src="../../_static/doctools.js"></script>
<link rel="top" title="Django 1.6.7 documentation" href="../../index.html" />
<link rel="up" title="Testing in Django" href="index.html" />
<link rel="next" title="Testing tools" href="tools.html" />
<link rel="prev" title="Testing in Django" href="index.html" />
<script type="text/javascript" src="../../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../../index.html">Django 1.6.7 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../../index.html">Home</a> |
<a title="Table of contents" href="../../contents.html">Table of contents</a> |
<a title="Global index" href="../../genindex.html">Index</a> |
<a title="Module index" href="../../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="index.html" title="Testing in Django">previous</a>
|
<a href="../index.html" title="Using Django" accesskey="U">up</a>
|
<a href="tools.html" title="Testing tools">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="topics-testing-overview">
<div class="section" id="s-module-django.test">
<span id="s-writing-and-running-tests"></span><span id="module-django.test"></span><span id="writing-and-running-tests"></span><h1>Writing and running tests<a class="headerlink" href="#module-django.test" title="Permalink to this headline">¶</a></h1>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">The <a class="reference internal" href="../../intro/tutorial05.html"><em>testing tutorial</em></a>, the <a class="reference internal" href="tools.html"><em>testing tools
reference</em></a>, and the <a class="reference internal" href="advanced.html"><em>advanced testing topics</em></a>.</p>
</div>
<p>This document is split into two primary sections. First, we explain how to write
tests with Django. Then, we explain how to run them.</p>
<div class="section" id="s-writing-tests">
<span id="writing-tests"></span><h2>Writing tests<a class="headerlink" href="#writing-tests" title="Permalink to this headline">¶</a></h2>
<p>Django’s unit tests use a Python standard library module: <tt class="xref py py-mod docutils literal"><span class="pre">unittest</span></tt>. This
module defines tests using a class-based approach.</p>
<div class="admonition-unittest2 admonition">
<p class="first admonition-title">unittest2</p>
<p>Python 2.7 introduced some major changes to the <tt class="docutils literal"><span class="pre">unittest</span></tt> library,
adding some extremely useful features. To ensure that every Django
project can benefit from these new features, Django ships with a
copy of <a class="reference external" href="https://pypi.python.org/pypi/unittest2">unittest2</a>, a copy of Python 2.7’s <tt class="docutils literal"><span class="pre">unittest</span></tt>, backported for
Python 2.6 compatibility.</p>
<p>To access this library, Django provides the
<tt class="docutils literal"><span class="pre">django.utils.unittest</span></tt> module alias. If you are using Python
2.7, or you have installed <tt class="docutils literal"><span class="pre">unittest2</span></tt> locally, Django will map the alias
to it. Otherwise, Django will use its own bundled version of <tt class="docutils literal"><span class="pre">unittest2</span></tt>.</p>
<p>To use this alias, simply use:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">unittest</span>
</pre></div>
</div>
<p>wherever you would have historically used:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">unittest</span>
</pre></div>
</div>
<p class="last">If you want to continue to use the legacy <tt class="docutils literal"><span class="pre">unittest</span></tt> library, you can –
you just won’t get any of the nice new <tt class="docutils literal"><span class="pre">unittest2</span></tt> features.</p>
</div>
<p>Here is an example which subclasses from <a class="reference internal" href="tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">django.test.TestCase</span></tt></a>,
which is a subclass of <tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt> that runs each test inside a
transaction to provide isolation:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.test</span> <span class="kn">import</span> <span class="n">TestCase</span>
<span class="kn">from</span> <span class="nn">myapp.models</span> <span class="kn">import</span> <span class="n">Animal</span>
<span class="k">class</span> <span class="nc">AnimalTestCase</span><span class="p">(</span><span class="n">TestCase</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">setUp</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">"lion"</span><span class="p">,</span> <span class="n">sound</span><span class="o">=</span><span class="s">"roar"</span><span class="p">)</span>
<span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">create</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">"cat"</span><span class="p">,</span> <span class="n">sound</span><span class="o">=</span><span class="s">"meow"</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">test_animals_can_speak</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="sd">"""Animals that can speak are correctly identified"""</span>
<span class="n">lion</span> <span class="o">=</span> <span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">"lion"</span><span class="p">)</span>
<span class="n">cat</span> <span class="o">=</span> <span class="n">Animal</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">get</span><span class="p">(</span><span class="n">name</span><span class="o">=</span><span class="s">"cat"</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">assertEqual</span><span class="p">(</span><span class="n">lion</span><span class="o">.</span><span class="n">speak</span><span class="p">(),</span> <span class="s">'The lion says "roar"'</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">assertEqual</span><span class="p">(</span><span class="n">cat</span><span class="o">.</span><span class="n">speak</span><span class="p">(),</span> <span class="s">'The cat says "meow"'</span><span class="p">)</span>
</pre></div>
</div>
<p>When you <a class="reference internal" href="#running-tests"><em>run your tests</em></a>, the default behavior of the
test utility is to find all the test cases (that is, subclasses of
<tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt>) in any file whose name begins with <tt class="docutils literal"><span class="pre">test</span></tt>,
automatically build a test suite out of those test cases, and run that suite.</p>
<div class="versionchanged">
<span class="title">Changed in Django 1.6:</span> Previously, Django’s default test runner only discovered tests in
<tt class="docutils literal"><span class="pre">tests.py</span></tt> and <tt class="docutils literal"><span class="pre">models.py</span></tt> files within a Python package listed in
<a class="reference internal" href="../../ref/settings.html#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a>.</div>
<p>For more details about <tt class="xref py py-mod docutils literal"><span class="pre">unittest</span></tt>, see the Python documentation.</p>
<div class="admonition warning">
<p class="first admonition-title">Warning</p>
<p>If your tests rely on database access such as creating or querying models,
be sure to create your test classes as subclasses of
<a class="reference internal" href="tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">django.test.TestCase</span></tt></a> rather than <tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt>.</p>
<p class="last">Using <tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt> avoids the cost of running each test in a
transaction and flushing the database, but if your tests interact with
the database their behavior will vary based on the order that the test
runner executes them. This can lead to unit tests that pass when run in
isolation but fail when run in a suite.</p>
</div>
</div>
<div class="section" id="s-running-tests">
<span id="s-id1"></span><span id="running-tests"></span><span id="id1"></span><h2>Running tests<a class="headerlink" href="#running-tests" title="Permalink to this headline">¶</a></h2>
<p>Once you’ve written tests, run them using the <a class="reference internal" href="../../ref/django-admin.html#django-admin-test"><tt class="xref std std-djadmin docutils literal"><span class="pre">test</span></tt></a> command of
your project’s <tt class="docutils literal"><span class="pre">manage.py</span></tt> utility:</p>
<div class="highlight-python"><pre>$ ./manage.py test</pre>
</div>
<p>Test discovery is based on the unittest module’s <em class="xref std std-ref">built-in test
discovery</em>. By default, this will discover tests in
any file named “test*.py” under the current working directory.</p>
<p>You can specify particular tests to run by supplying any number of “test
labels” to <tt class="docutils literal"><span class="pre">./manage.py</span> <span class="pre">test</span></tt>. Each test label can be a full Python dotted
path to a package, module, <tt class="docutils literal"><span class="pre">TestCase</span></tt> subclass, or test method. For instance:</p>
<div class="highlight-python"><pre># Run all the tests in the animals.tests module
$ ./manage.py test animals.tests
# Run all the tests found within the 'animals' package
$ ./manage.py test animals
# Run just one test case
$ ./manage.py test animals.tests.AnimalTestCase
# Run just one test method
$ ./manage.py test animals.tests.AnimalTestCase.test_animals_can_speak</pre>
</div>
<p>You can also provide a path to a directory to discover tests below that
directory:</p>
<div class="highlight-python"><pre>$ ./manage.py test animals/</pre>
</div>
<p>You can specify a custom filename pattern match using the <tt class="docutils literal"><span class="pre">-p</span></tt> (or
<tt class="docutils literal"><span class="pre">--pattern</span></tt>) option, if your test files are named differently from the
<tt class="docutils literal"><span class="pre">test*.py</span></tt> pattern:</p>
<div class="highlight-python"><pre>$ ./manage.py test --pattern="tests_*.py"</pre>
</div>
<div class="versionchanged">
<span class="title">Changed in Django 1.6:</span> Previously, test labels were in the form <tt class="docutils literal"><span class="pre">applabel</span></tt>,
<tt class="docutils literal"><span class="pre">applabel.TestCase</span></tt>, or <tt class="docutils literal"><span class="pre">applabel.TestCase.test_method</span></tt>, rather than
being true Python dotted paths, and tests could only be found within
<tt class="docutils literal"><span class="pre">tests.py</span></tt> or <tt class="docutils literal"><span class="pre">models.py</span></tt> files within a Python package listed in
<a class="reference internal" href="../../ref/settings.html#std:setting-INSTALLED_APPS"><tt class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></tt></a>. The <tt class="docutils literal"><span class="pre">--pattern</span></tt> option and file paths as test
labels are new in 1.6.</div>
<p>If you press <tt class="docutils literal"><span class="pre">Ctrl-C</span></tt> while the tests are running, the test runner will
wait for the currently running test to complete and then exit gracefully.
During a graceful exit the test runner will output details of any test
failures, report on how many tests were run and how many errors and failures
were encountered, and destroy any test databases as usual. Thus pressing
<tt class="docutils literal"><span class="pre">Ctrl-C</span></tt> can be very useful if you forget to pass the <a class="reference internal" href="../../ref/django-admin.html#django-admin-option---failfast"><tt class="xref std std-djadminopt docutils literal"><span class="pre">--failfast</span></tt></a>
option, notice that some tests are unexpectedly failing, and want to get details
on the failures without waiting for the full test run to complete.</p>
<p>If you do not want to wait for the currently running test to finish, you
can press <tt class="docutils literal"><span class="pre">Ctrl-C</span></tt> a second time and the test run will halt immediately,
but not gracefully. No details of the tests run before the interruption will
be reported, and any test databases created by the run will not be destroyed.</p>
<div class="admonition-test-with-warnings-enabled admonition">
<p class="first admonition-title">Test with warnings enabled</p>
<p class="last">It’s a good idea to run your tests with Python warnings enabled:
<tt class="docutils literal"><span class="pre">python</span> <span class="pre">-Wall</span> <span class="pre">manage.py</span> <span class="pre">test</span></tt>. The <tt class="docutils literal"><span class="pre">-Wall</span></tt> flag tells Python to
display deprecation warnings. Django, like many other Python libraries,
uses these warnings to flag when features are going away. It also might
flag areas in your code that aren’t strictly wrong but could benefit
from a better implementation.</p>
</div>
<div class="section" id="s-the-test-database">
<span id="s-id2"></span><span id="the-test-database"></span><span id="id2"></span><h3>The test database<a class="headerlink" href="#the-test-database" title="Permalink to this headline">¶</a></h3>
<p>Tests that require a database (namely, model tests) will not use your “real”
(production) database. Separate, blank databases are created for the tests.</p>
<p>Regardless of whether the tests pass or fail, the test databases are destroyed
when all the tests have been executed.</p>
<p>By default the test databases get their names by prepending <tt class="docutils literal"><span class="pre">test_</span></tt>
to the value of the <a class="reference internal" href="../../ref/settings.html#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> settings for the databases
defined in <a class="reference internal" href="../../ref/settings.html#std:setting-DATABASES"><tt class="xref std std-setting docutils literal"><span class="pre">DATABASES</span></tt></a>. When using the SQLite database engine
the tests will by default use an in-memory database (i.e., the
database will be created in memory, bypassing the filesystem
entirely!). If you want to use a different database name, specify
<a class="reference internal" href="../../ref/settings.html#std:setting-TEST_NAME"><tt class="xref std std-setting docutils literal"><span class="pre">TEST_NAME</span></tt></a> in the dictionary for any given database in
<a class="reference internal" href="../../ref/settings.html#std:setting-DATABASES"><tt class="xref std std-setting docutils literal"><span class="pre">DATABASES</span></tt></a>.</p>
<p>Aside from using a separate database, the test runner will otherwise
use all of the same database settings you have in your settings file:
<a class="reference internal" href="../../ref/settings.html#std:setting-DATABASE-ENGINE"><tt class="xref std std-setting docutils literal"><span class="pre">ENGINE</span></tt></a>, <a class="reference internal" href="../../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a>, <a class="reference internal" href="../../ref/settings.html#std:setting-HOST"><tt class="xref std std-setting docutils literal"><span class="pre">HOST</span></tt></a>, etc. The
test database is created by the user specified by <a class="reference internal" href="../../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a>, so you’ll
need to make sure that the given user account has sufficient privileges to
create a new database on the system.</p>
<p>For fine-grained control over the character encoding of your test
database, use the <a class="reference internal" href="../../ref/settings.html#std:setting-TEST_CHARSET"><tt class="xref std std-setting docutils literal"><span class="pre">TEST_CHARSET</span></tt></a> option. If you’re using
MySQL, you can also use the <a class="reference internal" href="../../ref/settings.html#std:setting-TEST_COLLATION"><tt class="xref std std-setting docutils literal"><span class="pre">TEST_COLLATION</span></tt></a> option to
control the particular collation used by the test database. See the
<a class="reference internal" href="../../ref/settings.html"><em>settings documentation</em></a> for details of these
advanced settings.</p>
<div class="admonition-finding-data-from-your-production-database-when-running-tests admonition">
<p class="first admonition-title">Finding data from your production database when running tests?</p>
<p class="last">If your code attempts to access the database when its modules are compiled,
this will occur <em>before</em> the test database is set up, with potentially
unexpected results. For example, if you have a database query in
module-level code and a real database exists, production data could pollute
your tests. <em>It is a bad idea to have such import-time database queries in
your code</em> anyway - rewrite your code so that it doesn’t do this.</p>
</div>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">The <a class="reference internal" href="advanced.html#topics-testing-advanced-multidb"><em>advanced multi-db testing topics</em></a>.</p>
</div>
</div>
<div class="section" id="s-order-in-which-tests-are-executed">
<span id="s-order-of-tests"></span><span id="order-in-which-tests-are-executed"></span><span id="order-of-tests"></span><h3>Order in which tests are executed<a class="headerlink" href="#order-in-which-tests-are-executed" title="Permalink to this headline">¶</a></h3>
<p>In order to guarantee that all <tt class="docutils literal"><span class="pre">TestCase</span></tt> code starts with a clean database,
the Django test runner reorders tests in the following way:</p>
<ul class="simple">
<li>All <a class="reference internal" href="tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">TestCase</span></tt></a> subclasses are run first.</li>
<li>Then, all other unittests (including <tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt>,
<a class="reference internal" href="tools.html#django.test.SimpleTestCase" title="django.test.SimpleTestCase"><tt class="xref py py-class docutils literal"><span class="pre">SimpleTestCase</span></tt></a> and
<a class="reference internal" href="tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a>) are run with no particular
ordering guaranteed nor enforced among them.</li>
<li>Then any other tests (e.g. doctests) that may alter the database without
restoring it to its original state are run.</li>
</ul>
<div class="versionchanged">
<span class="title">Changed in Django 1.5:</span> Before Django 1.5, the only guarantee was that
<a class="reference internal" href="tools.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">TestCase</span></tt></a> tests were always ran first, before any other
tests.</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The new ordering of tests may reveal unexpected dependencies on test case
ordering. This is the case with doctests that relied on state left in the
database by a given <a class="reference internal" href="tools.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> test, they
must be updated to be able to run independently.</p>
</div>
</div>
<div class="section" id="s-other-test-conditions">
<span id="other-test-conditions"></span><h3>Other test conditions<a class="headerlink" href="#other-test-conditions" title="Permalink to this headline">¶</a></h3>
<p>Regardless of the value of the <a class="reference internal" href="../../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a> setting in your configuration
file, all Django tests run with <a class="reference internal" href="../../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a>=False. This is to ensure that
the observed output of your code matches what will be seen in a production
setting.</p>
<p>Caches are not cleared after each test, and running “manage.py test fooapp” can
insert data from the tests into the cache of a live system if you run your
tests in production because, unlike databases, a separate “test cache” is not
used. This behavior <a class="reference external" href="https://code.djangoproject.com/ticket/11505">may change</a> in the future.</p>
</div>
<div class="section" id="s-understanding-the-test-output">
<span id="understanding-the-test-output"></span><h3>Understanding the test output<a class="headerlink" href="#understanding-the-test-output" title="Permalink to this headline">¶</a></h3>
<p>When you run your tests, you’ll see a number of messages as the test runner
prepares itself. You can control the level of detail of these messages with the
<tt class="docutils literal"><span class="pre">verbosity</span></tt> option on the command line:</p>
<div class="highlight-python"><pre>Creating test database...
Creating table myapp_animal
Creating table myapp_mineral
Loading 'initial_data' fixtures...
No fixtures found.</pre>
</div>
<p>This tells you that the test runner is creating a test database, as described
in the previous section.</p>
<p>Once the test database has been created, Django will run your tests.
If everything goes well, you’ll see something like this:</p>
<div class="highlight-python"><pre>----------------------------------------------------------------------
Ran 22 tests in 0.221s
OK</pre>
</div>
<p>If there are test failures, however, you’ll see full details about which tests
failed:</p>
<div class="highlight-python"><pre>======================================================================
FAIL: test_was_published_recently_with_future_poll (polls.tests.PollMethodTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/dev/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_poll
self.assertEqual(future_poll.was_published_recently(), False)
AssertionError: True != False
----------------------------------------------------------------------
Ran 1 test in 0.003s
FAILED (failures=1)</pre>
</div>
<p>A full explanation of this error output is beyond the scope of this document,
but it’s pretty intuitive. You can consult the documentation of Python’s
<tt class="xref py py-mod docutils literal"><span class="pre">unittest</span></tt> library for details.</p>
<p>Note that the return code for the test-runner script is 1 for any number of
failed and erroneous tests. If all the tests pass, the return code is 0. This
feature is useful if you’re using the test-runner script in a shell script and
need to test for success or failure at that level.</p>
</div>
<div class="section" id="s-speeding-up-the-tests">
<span id="speeding-up-the-tests"></span><h3>Speeding up the tests<a class="headerlink" href="#speeding-up-the-tests" title="Permalink to this headline">¶</a></h3>
<p>In recent versions of Django, the default password hasher is rather slow by
design. If during your tests you are authenticating many users, you may want
to use a custom settings file and set the <a class="reference internal" href="../../ref/settings.html#std:setting-PASSWORD_HASHERS"><tt class="xref std std-setting docutils literal"><span class="pre">PASSWORD_HASHERS</span></tt></a> setting
to a faster hashing algorithm:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">PASSWORD_HASHERS</span> <span class="o">=</span> <span class="p">(</span>
<span class="s">'django.contrib.auth.hashers.MD5PasswordHasher'</span><span class="p">,</span>
<span class="p">)</span>
</pre></div>
</div>
<p>Don’t forget to also include in <a class="reference internal" href="../../ref/settings.html#std:setting-PASSWORD_HASHERS"><tt class="xref std std-setting docutils literal"><span class="pre">PASSWORD_HASHERS</span></tt></a> any hashing
algorithm used in fixtures, if any.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Writing and running tests</a><ul>
<li><a class="reference internal" href="#writing-tests">Writing tests</a></li>
<li><a class="reference internal" href="#running-tests">Running tests</a><ul>
<li><a class="reference internal" href="#the-test-database">The test database</a></li>
<li><a class="reference internal" href="#order-in-which-tests-are-executed">Order in which tests are executed</a></li>
<li><a class="reference internal" href="#other-test-conditions">Other test conditions</a></li>
<li><a class="reference internal" href="#understanding-the-test-output">Understanding the test output</a></li>
<li><a class="reference internal" href="#speeding-up-the-tests">Speeding up the tests</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="index.html">Testing in Django</a></li>
<li>Next: <a href="tools.html">Testing tools</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../../index.html">Django 1.6.7 documentation</a>
<ul><li><a href="../index.html">Using Django</a>
<ul><li><a href="index.html">Testing in Django</a>
<ul><li>Writing and running tests</li></ul>
</li></ul></li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../../_sources/topics/testing/overview.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Sep 26, 2014</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="index.html" title="Testing in Django">previous</a>
|
<a href="../index.html" title="Using Django" accesskey="U">up</a>
|
<a href="tools.html" title="Testing tools">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
