test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

[1.2.X] Fixed #13662 -- Added an entry in the README to direct people to the instructions for running the test suite, and cleaned up that section of the docs. Thanks to mir for the report, and to cogat and gg for the draft text. 

Backport of r15342 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@15345 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2011-01-27 03:52:44 +00:00
parent d073d30e45
commit 8ab768f935
2 changed files with 82 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README
View File

@ -35,3 +35,9 @@ To contribute to Django:
* Check out http://www.djangoproject.com/community/ for information
about getting involved.
To run Django's test suite:
* Follow the instructions in the "Unit tests" section of
docs/internals/contributing.txt, published online at
http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests

134
docs/internals/contributing.txt
View File

@ -827,29 +827,29 @@ discovered, please follow these guidelines:
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
original author.
* 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,
say), wait it out.
* 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
be put to a vote.
* If the commit introduced a confirmed, disclosed security
vulnerability then the commit may be reverted immediately without
permission from anyone.
* The release branch maintainer may back out commits to the release
branch without permission if the commit breaks the release branch.
@ -878,14 +878,41 @@ for an explanation of how to write new tests.
Running the unit tests
----------------------
To run the tests, ``cd`` to the ``tests/`` directory and type:
Quickstart
~~~~~~~~~~
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:
.. code-block:: bash
./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
Django version`_ below.
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
and type:
.. code-block:: bash
./runtests.py --settings=path.to.django.settings
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
two databases:
* A ``default`` database. This database should use the backend that
you want to use for primary testing
@ -896,38 +923,8 @@ info. Your :setting:`DATABASES` setting needs to define two databases:
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::
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3'
},
'other': {
'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
cases.
To run the tests with this included settings file, ``cd``
to the ``tests/`` directory and type:
.. code-block:: bash
./runtests.py --settings=test_sqlite
If you're using another backend, you will need to provide other details for
each database:
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.
@ -947,6 +944,40 @@ character set. If your database server doesn't use UTF-8 as a default charset,
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``
command line.
As an example, if you'd like to only run tests for generic relations and
internationalization, type:
.. code-block:: bash
./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:
.. code-block:: bash
./runtests.py --settings=path.to.settings i18n.TranslationTests
You can specify an individual test like this:
.. code-block:: bash
./runtests.py --settings=path.to.settings i18n.TranslationTests.test_lazy_objects
Running all the tests
~~~~~~~~~~~~~~~~~~~~~
If you want to run the full suite of tests, you'll need to install a number of
dependencies:
@ -975,19 +1006,6 @@ associated tests will be skipped.
.. _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:
.. code-block:: bash
PYTHONPATH=`pwd`/..
./runtests.py --settings=settings generic_relations i18n
Contrib apps
------------
@ -1234,9 +1252,9 @@ voting mechanism above. A proposition will be considered carried by the core tea
if:
* 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
veto.
@ -1263,7 +1281,7 @@ Core committers
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.
Partial committers
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