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

Split up the documentation of the test database and the test output. 

Refs #6134.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@6929 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Malcolm Tredinnick 2007-12-17 08:50:32 +00:00
parent 4a25cf5d95
commit 8ecff6b91c
1 changed files with 27 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
docs/testing.txt
View File

@ -270,27 +270,20 @@ a test case, add the name of the test method to the label::
$ ./manage.py test animals.AnimalTestCase.testFluffyAnimals $ ./manage.py test animals.AnimalTestCase.testFluffyAnimals
Understanding the test output The test database
----------------------------- -----------------
When you run your tests, you'll see a number of messages as the test runner Tests that require a database (namely, model tests) will not use
prepares itself:: your "real" (production) database. A separate, blank database is created
for the tests.
Creating test database... Regardless of whether the tests pass or fail, the test database is destroyed
Creating table myapp_animal when all the tests have been executed.
Creating table myapp_mineral
Loading 'initial_data' fixtures...
No fixtures found.
This tells you that the test runner is creating a test database -- a blank, By default this test database gets its name by prepending ``test_`` to the
from-scratch database that it will use for any tests that happen to require a value of the ``DATABASE_NAME`` setting. When using the SQLite database engine
database (namely, model tests). the tests will by default use a memory resident database. If you want to use
a different database name, specify the ``TEST_DATABASE_NAME`` setting.
Don't worry -- the test runner will not touch your "real" (production)
database. It creates a separate database purely for the tests. This test
database gets its name by prepending ``test_`` to the value of the
``DATABASE_NAME`` setting. If you want to use a different name, specify the
``TEST_DATABASE_NAME`` setting.
Aside from using a separate database, the test runner will otherwise use all of 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``, the same database settings you have in your settings file: ``DATABASE_ENGINE``,
@ -306,6 +299,22 @@ settings_ documentation for details of these advanced settings.
.. _settings: ../settings/ .. _settings: ../settings/
Understanding the test output
-----------------------------
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
``verbosity`` option on the command line::
Creating test database...
Creating table myapp_animal
Creating table myapp_mineral
Loading 'initial_data' fixtures...
No fixtures found.
This tells you that the test runner is creating a test database, as described
in the previous section.
Once the test database has been created, Django will run your tests. Once the test database has been created, Django will run your tests.
If everything goes well, you'll see something like this:: If everything goes well, you'll see something like this::
@ -349,9 +358,6 @@ 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 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. need to test for success or failure at that level.
Regardless of whether the tests pass or fail, the test database is destroyed when
all the tests have been executed.
Testing tools Testing tools
============= =============