mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 22:26:08 +00:00
Code Issues 32 Releases Wiki Activity

[soc2009/multidb] Renaming of database attributes - you now use NAME, ENGINE, etc rather than DATABASE_NAME, DATABASE_ENGINE inside DATABASES. Also deprecates the use of short names (.e.g., `sqlite3` for backends in ENGINE). Patch from Russell Keith-Magee.

Browse Source 
Conflicts:

	docs/releases/1.2.txt

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/multidb@11775 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Alex Gaynor
2009-11-23 16:45:41 +00:00
parent 3e6ae729bc
commit 4e36fffab2
55 changed files with 628 additions and 425 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
docs/topics/testing.txt
View File

@@ -278,33 +278,35 @@ The test database
-----------------
Tests that require a database (namely, model tests) will not use your "real"
(production) database. A separate, blank database is created for the tests.
(production) database. Separate, blank databases are created for the tests.
Regardless of whether the tests pass or fail, the test database is destroyed
Regardless of whether the tests pass or fail, the test databases are destroyed
when all the tests have been executed.
By default this test database gets its name by prepending ``test_`` to the
value of the ``DATABASE_NAME`` setting. 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 ``TEST_DATABASE_NAME`` in the dictionary
for any given database in :setting:`DATABASES`.
By default the test databases get their names by prepending ``test_``
to the value of the :setting:`NAME`` settings for the databased
defined in :setting:`DATABASES`. 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
``TEST_NAME`` in the dictionary for any given database in
:setting:`DATABASES`.
Aside from using a separate database, the test runner will otherwise use all of
the same database settings you have in your settings file:
``DATABASE_ENGINE``, ``DATABASE_USER``, ``DATABASE_HOST``,
etc. The test database is created by the user specified by
``DATABASE_USER``, so you'll need to make sure that the given user
account has sufficient privileges to create a new database on the system.
Aside from using a separate database, the test runner will otherwise
use all of the same database settings you have in your settings file:
:setting:`ENGINE`, :setting:`USER`, :setting:`HOST`, etc. The test
database is created by the user specified by ``USER``, so you'll need
to make sure that the given user account has sufficient privileges to
create a new database on the system.
.. versionadded:: 1.0
For fine-grained control over the
character encoding of your test database, use the
``TEST_DATABASE_CHARSET`` option. If you're using MySQL, you can also
use the ``TEST_DATABASE_COLLATION`` option to control the particular
collation used by the test database. See the :ref:`settings documentation
<ref-settings>` for details of these advanced settings.
For fine-grained control over the character encoding of your test
database, use the :setting:`TEST_CHARSET` option. If you're using
MySQL, you can also use the :setting:`TEST_COLLATION` option to
control the particular collation used by the test database. See the
:ref:`settings documentation <ref-settings>` for details of these
advanced settings.
Other test conditions
---------------------
@@ -1284,16 +1286,17 @@ utility methods in the ``django.test.utils`` module.
.. function:: setup_test_environment()
Performs any global pre-test setup, such as the installing the
instrumentation of the template rendering system and setting up the dummy
``SMTPConnection``.
instrumentation of the template rendering system and setting up
the dummy ``SMTPConnection``.
.. function:: teardown_test_environment()
Performs any global post-test teardown, such as removing the black magic
hooks into the template system and restoring normal e-mail services.
Performs any global post-test teardown, such as removing the black
magic hooks into the template system and restoring normal e-mail
services.
The creation module of the database backend (``connection.creation``) also
provides some utilities that can be useful during testing.
The creation module of the database backend (``connection.creation``)
also provides some utilities that can be useful during testing.
.. function:: create_test_db(verbosity=1, autoclobber=False)
@@ -1301,27 +1304,29 @@ provides some utilities that can be useful during testing.
``verbosity`` has the same behavior as in ``run_tests()``.
``autoclobber`` describes the behavior that will occur if a database with
the same name as the test database is discovered:
``autoclobber`` describes the behavior that will occur if a
database with the same name as the test database is discovered:
* If ``autoclobber`` is ``False``, the user will be asked to approve
destroying the existing database. ``sys.exit`` is called if the user
does not approve.
* If ``autoclobber`` is ``False``, the user will be asked to
approve destroying the existing database. ``sys.exit`` is
called if the user does not approve.
* If autoclobber is ``True``, the database will be destroyed without
consulting the user.
* If autoclobber is ``True``, the database will be destroyed
without consulting the user.
Returns the name of the test database that it created.
``create_test_db()`` has the side effect of modifying
``settings.DATABASE_NAME`` to match the name of the test database.
``create_test_db()`` has the side effect of modifying the value of
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
database.
.. versionchanged:: 1.0
``create_test_db()`` now returns the name of the test database.
.. function:: destroy_test_db(old_database_name, verbosity=1)
Destroys the database whose name is in the :setting:`DATABASE_NAME` setting
and restores the value of :setting:`DATABASE_NAME` to the provided name.
Destroys the database whose name is in stored in :setting:`NAME` in the
:setting:`DATABASES`, and sets :setting:`NAME` to use the
provided name.
``verbosity`` has the same behavior as in ``run_tests()``.