Django comes with a test suite of its own, in the tests directory of the\ncode base. It’s our policy to make sure all tests pass at all times.
We appreciate any and all contributions to the test suite!
\nThe Django tests all use the testing infrastructure that ships with Django for\ntesting applications. See Writing and running tests for an explanation of\nhow to write new tests.
\nIf you are on Python 2, you’ll first need to install a backport of the\nunittest.mock module that’s available in Python 3. See\nRunning all the tests for details on installing mock and\nthe other optional test dependencies.
Running the tests requires a Django settings module that defines the\ndatabases to use. To make it easy to get started, Django provides and uses a\nsample settings module that uses the SQLite database. To run the tests:
\n$ git clone https://github.com/django/django.git django-repo\n$ cd django-repo/tests\n$ PYTHONPATH=..:$PYTHONPATH ./runtests.py\nYou can avoid typing the PYTHONPATH bit each time by adding your Django\ncheckout to your PYTHONPATH or by installing the source checkout using pip.\nSee Installing the development version.
Having problems? See Troubleshooting for some common issues.
\nsettings moduleLink to this heading#The included settings module allows you to run the test suite using\nSQLite. If you want to test behavior using a different database (and\nif you’re proposing patches for Django, it’s a good idea to test\nacross databases), you may need to define your own settings file.
\nTo run the tests with different settings, ensure that the module is on your\nPYTHONPATH and pass the module with --settings.
The DATABASES setting in any test settings module needs to define\ntwo databases:
A default database. This database should use the backend that\nyou want to use for primary testing.
A database with the alias other. The other database is used to\nestablish that queries can be directed to different databases. As a result,\nthis database can use any backend you want. It doesn’t need to use the same\nbackend as the default database (although it can use the same backend if\nyou want to). It cannot be the same database as the default.
If you’re using a backend that isn’t SQLite, you will need to provide other\ndetails for each database:
\nThe USER option needs to specify an existing user account\nfor the database. That user needs permission to execute CREATE DATABASE\nso that the test database can be created.
The PASSWORD option needs to provide the password for\nthe USER that has been specified.
Test databases get their names by prepending test_ to the value of the\nNAME settings for the databases defined in DATABASES.\nThese test databases are deleted when the tests are finished.
You will also need to ensure that your database uses UTF-8 as the default\ncharacter set. If your database server doesn’t use UTF-8 as a default charset,\nyou will need to include a value for CHARSET in the\ntest settings dictionary for the applicable database.
Django’s entire test suite takes a while to run, and running every single test\ncould be redundant if, say, you just added a test to Django that you want to\nrun quickly without running everything else. You can run a subset of the unit\ntests by appending the names of the test modules to runtests.py on the\ncommand line.
For example, if you’d like to run tests only for generic relations and\ninternationalization, type:
\n$ ./runtests.py --settings=path.to.settings generic_relations i18n\nHow do you find out the names of individual tests? Look in tests/ — each\ndirectory name there is the name of a test.
If you just want to run a particular class of tests, you can specify a list of\npaths to individual test classes. For example, to run the TranslationTests\nof the i18n module, type:
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests\nGoing beyond that, you can specify an individual test method like this:
\n$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects\nSome tests require Selenium and a Web browser (Firefox, Google Chrome, or\nInternet Explorer). To allow those tests to be run rather than skipped, you must\ninstall the selenium package into your Python path and run the tests with the\n--selenium option:
$ ./runtests.py --settings=test_sqlite --selenium admin_inlines\nIf you want to run the full suite of tests, you’ll need to install a number of\ndependencies:
\njinja2 2.7+
memcached, plus a supported Python binding
mock (for Python 2)
You can find these dependencies in pip requirements files inside the\ntests/requirements directory of the Django source tree and install them\nlike so:
$ pip install -r tests/requirements/py3.txt # Python 2: py2.txt\nYou can also install the database adapter(s) of your choice using\noracle.txt, mysql.txt, or postgres.txt.
If you want to test the memcached cache backend, you’ll also need to define\na CACHES setting that points at your memcached instance.
To run the GeoDjango tests, you will need to setup a spatial database\nand install the Geospatial libraries.
\nEach of these dependencies is optional. If you’re missing any of them, the\nassociated tests will be skipped.
\nContributors are encouraged to run coverage on the test suite to identify areas\nthat need additional tests. The coverage tool installation and use is described\nin testing code coverage.
\nCoverage should be run in a single process to obtain accurate statistics. To\nrun coverage on the Django test suite using the standard test settings:
\n$ coverage run ./runtests.py --settings=test_sqlite --parallel=1\nAfter running coverage, generate the html report by running:
\n$ coverage html\nWhen running coverage for the Django tests, the included .coveragerc\nsettings file defines coverage_html as the output directory for the report\nand also excludes several directories not relevant to the results\n(test code or external code included in Django).
Tests for contrib apps can be found in the tests/ directory, typically\nunder <app_name>_tests. For example, tests for contrib.auth are located\nin tests/auth_tests.
UnicodeEncodeErrorLink to this heading#If the locales package is not installed, some tests will fail with a\nUnicodeEncodeError.
You can resolve this on Debian-based systems, for example, by running:
\n$ apt-get install locales\n$ dpkg-reconfigure locales\nIn case a test passes when run in isolation but fails within the whole suite,\nwe have some tools to help analyze the problem.
\nThe --bisect option of runtests.py will run the failing test while\nhalving the test set it is run together with on each iteration, often making\nit possible to identify a small number of tests that may be related to the\nfailure.
For example, suppose that the failing test that works on its own is\nModelTest.test_eq, then using:
$ ./runtests.py --bisect basic.tests.ModelTest.test_eq\nwill try to determine a test that interferes with the given one. First, the\ntest is run with the first half of the test suite. If a failure occurs, the\nfirst half of the test suite is split in two groups and each group is then run\nwith the specified test. If there is no failure with the first half of the test\nsuite, the second half of the test suite is run with the specified test and\nsplit appropriately as described earlier. The process repeats until the set of\nfailing tests is minimized.
\nThe --pair option runs the given test alongside every other test from the\nsuite, letting you check if another test has side-effects that cause the\nfailure. So:
$ ./runtests.py --pair basic.tests.ModelTest.test_eq\nwill pair test_eq with every test label.
With both --bisect and --pair, if you already suspect which cases\nmight be responsible for the failure, you may limit tests to be cross-analyzed\nby specifying further test labels after\nthe first one:
$ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions\nYou can also try running any set of tests in reverse using the --reverse\noption in order to verify that executing tests in a different order does not\ncause any trouble:
$ ./runtests.py basic --reverse\nIf you wish to examine the SQL being run in failing tests, you can turn on\nSQL logging using the --debug-sql option. If you\ncombine this with --verbosity=2, all SQL queries will be output:
$ ./runtests.py basic --debug-sql\nBy default tests are run in parallel with one process per core. When the tests\nare run in parallel, however, you’ll only see a truncated traceback for any\ntest failures. You can adjust this behavior with the --parallel option:
$ ./runtests.py basic --parallel=1\nYou can also use the DJANGO_TEST_PROCESSES environment variable for this\npurpose.