From ca33d307dee3cf68cc9cd2ccfae00c7ff23ea890 Mon Sep 17 00:00:00 2001 From: Adrian Holovaty Date: Sat, 15 Sep 2007 21:57:25 +0000 Subject: queryset-refactor: Merged to [6300] git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@6340 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/testing.txt | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) (limited to 'docs/testing.txt') diff --git a/docs/testing.txt b/docs/testing.txt index e15abd50d5..04c999cda8 100644 --- a/docs/testing.txt +++ b/docs/testing.txt @@ -137,12 +137,14 @@ When you `run your tests`_, the test runner will find this docstring, notice that portions of it look like an interactive Python session, and execute those lines while checking that the results match. -In the case of model tests, note that the test runner takes care of creating -its own test database. That is, any test that accesses a database -- by -creating and saving model instances, for example -- will not affect your -production database. Each doctest begins with a "blank slate" -- a fresh -database containing an empty table for each model. (See the section on -fixtures, below, for more on this.) +In the case of model tests, note that the test runner takes care of +creating its own test database. That is, any test that accesses a +database -- by creating and saving model instances, for example -- +will not affect your production database. Each doctest begins with a +"blank slate" -- a fresh database containing an empty table for each +model. (See the section on fixtures, below, for more on this.) Note +that to use this feature, the database user Django is connecting as +must have ``CREATE DATABASE`` rights. For more details about how doctest works, see the `standard library documentation for doctest`_ -- cgit v1.3