From 8ecff6b91c9cb8fac466552e36cfbdb3d5145148 Mon Sep 17 00:00:00 2001
From: Malcolm Tredinnick <malcolm.tredinnick@gmail.com>
Date: Mon, 17 Dec 2007 08:50:32 +0000
Subject: [PATCH] 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
---
 docs/testing.txt | 48 +++++++++++++++++++++++++++---------------------
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/docs/testing.txt b/docs/testing.txt
index 7705380eff..21b1f4d6a2 100644
--- a/docs/testing.txt
+++ b/docs/testing.txt
@@ -270,27 +270,20 @@ a test case, add the name of the test method to the label::
 
     $ ./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
-prepares itself::
+Tests that require a database (namely, model tests) will not use
+your "real" (production) database. A separate, blank database is created
+for the tests.
 
-    Creating test database...
-    Creating table myapp_animal
-    Creating table myapp_mineral
-    Loading 'initial_data' fixtures...
-    No fixtures found.
+Regardless of whether the tests pass or fail, the test database is destroyed
+when all the tests have been executed.
 
-This tells you that the test runner is creating a test database -- a blank,
-from-scratch database that it will use for any tests that happen to require a
-database (namely, model tests).
-
-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.
+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 a memory resident database. If you want to use
+a different database name, specify the ``TEST_DATABASE_NAME`` setting.
 
 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``,
@@ -306,6 +299,22 @@ settings_ documentation for details of these advanced 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.
 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
 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
 =============