gis: Merged revisions 6920-6989 via svnmerge from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@6990 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 28 insertions, 21 deletions

diff --git a/docs/testing.txt b/docs/testing.txt
index 7705380eff..54b8ba9ae6 100644
--- a/docs/testing.txt
+++ b/docs/testing.txt
@@ -270,27 +270,21 @@ a test case, add the name of the test method to the label::
 
     $ ./manage.py test animals.AnimalTestCase.testFluffyAnimals
 
-Understanding the test output
------------------------------
-
-When you run your tests, you'll see a number of messages as the test runner
-prepares itself::
+The test database
+-----------------
 
-    Creating test database...
-    Creating table myapp_animal
-    Creating table myapp_mineral
-    Loading 'initial_data' fixtures...
-    No fixtures found.
+Tests that require a database (namely, model tests) will not use
+your "real" (production) database. A separate, blank database is created
+for the tests.
 
-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).
+Regardless of whether the tests pass or fail, the test database is destroyed
+when all the tests have been executed.
 
-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 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 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 +300,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 +359,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
 =============