have a reversion policy doesn't relax your responsibility to aim for
the highest quality possible. Really: double-check your work before
you commit it in the first place!
* If possible, have the original author revert his/her own commit.
* Don't revert another author's changes without permission from the
* If the original author can't be reached (within a reasonable amount
of time -- a day or so) and the problem is severe -- crashing bug,
major test failures, etc -- then ask for objections on django-dev
then revert if there are none.
* If the problem is small (a feature commit after feature freeze,
* If there's a disagreement between the committer and the
reverter-to-be then try to work it out on the `django-developers`_
mailing list. If an agreement can't be reached then it should
* If the commit introduced a confirmed, disclosed security
vulnerability then the commit may be reverted immediately without
* The release branch maintainer may back out commits to the release
branch without permission if the commit breaks the release branch.
-To run the tests, ``cd`` to the ``tests/`` directory and type:
+Running the tests requires a Django settings module that defines the
+databases to use. To make it easy to get started. Django provides a
+sample settings module that uses the SQLite database. To run the tests
+with this sample ``settings`` module, ``cd`` into the Django
+``tests/`` directory and run:
+ ./runtests.py --settings=test_sqlite
+If you get an ``ImportError: No module named django.contrib`` error,
+you need to add your install of Django to your ``PYTHONPATH``. For
+more details on how to do this, read `Pointing Python at the new
+Using another ``settings`` module
+The included settings module allows you to run the test suite using
+SQLite. If you want to test behavior using a different database (and
+if you're proposing patches for Django, it's a good idea to test
+across databases), you may need to define your own settings file.
+To run the tests with different settings, ``cd`` to the ``tests/`` directory
-Yes, the unit tests need a settings module, but only for database connection
-info. Your :setting:`DATABASES` setting needs to define two databases:
+The :setting:`DATABASES` setting in this test settings module needs to define
* A ``default`` database. This database should use the backend that
you want to use for primary testing
want. It doesn't need to use the same backend as the ``default``
database (although it can use the same backend if you want to).
-If you're using the SQLite database backend, you need to define
-:setting:`ENGINE` for both databases, plus a
-:setting:`TEST_NAME` for the ``other`` database. The
-following is a minimal settings file that can be used to test SQLite::
- 'ENGINE': 'django.db.backends.sqlite3'
- 'ENGINE': 'django.db.backends.sqlite3',
- 'TEST_NAME': 'other_db'
-As a convenience, this settings file is included in your Django
-distribution. It is called ``test_sqlite``, and is included in
-the ``tests`` directory. This allows you to get started running
-the tests against the sqlite database without doing anything on
-your filesystem. However it should be noted that running against
-other database backends is recommended for certain types of test
-To run the tests with this included settings file, ``cd``
-to the ``tests/`` directory and type:
- ./runtests.py --settings=test_sqlite
-If you're using another backend, you will need to provide other details for
+If you're using a backend that isn't SQLite, you will need to provide other
+details for each database:
* The :setting:`USER` option for each of your databases needs to
specify an existing user account for the database.
you will need to include a value for ``TEST_CHARSET`` in the settings
dictionary for the applicable database.
+Running only some of the tests
+Django's entire test suite takes a few minutes to run. To run a subset of the
+unit tests, append the names of the test modules to the ``runtests.py``
+As an example, if you'd like to only run tests for generic relations and
+ ./runtests.py --settings=path.to.settings generic_relations i18n
+See the list of directories in ``tests/modeltests`` and
+``tests/regressiontests`` for module names.
+If you just want to run a particular class of tests, you can specify a list of
+paths to individual test classes. For example, to run the ``TranslationTests``
+of the ``i18n`` module, type:
+ ./runtests.py --settings=path.to.settings i18n.TranslationTests
+You can specify an individual test like this:
+ ./runtests.py --settings=path.to.settings i18n.TranslationTests.test_lazy_objects
If you want to run the full suite of tests, you'll need to install a number of
.. _cmemcached: http://gijsbert.org/cmemcache/index.html
.. _gettext: http://www.gnu.org/software/gettext/manual/gettext.html
-To run a subset of the unit tests, append the names of the test modules to the
-``runtests.py`` command line. See the list of directories in
-``tests/modeltests`` and ``tests/regressiontests`` for module names.
-As an example, if Django is not in your ``PYTHONPATH``, you placed
-``settings.py`` in the ``tests/`` directory, and you'd like to only run tests
-for generic relations and internationalization, type:
- ./runtests.py --settings=settings generic_relations i18n
* There are three "+1" votes from members of the core team.
* There is no "-1" vote from any member of the core team.
* The BDFLs haven't stepped in and executed their positive or negative
codebase, a solid track record of being polite and helpful on the
mailing lists, and a proven desire to dedicate serious time to Django's
development. The bar is high for full commit access.
These are people who are "domain experts." They have direct check-in access
to the subsystems that fall under their jurisdiction, and they're given a