Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

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
  • Loading branch information...
commit 8ecff6b91c9cb8fac466552e36cfbdb3d5145148 1 parent 4a25cf5
Malcolm Tredinnick malcolmt authored
Showing with 27 additions and 21 deletions.
  1. +27 −21 docs/testing.txt
48 docs/testing.txt
View
@@ -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
------------------------------
-
-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 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
=============
Please sign in to comment.
Something went wrong with that request. Please try again.