Ticket #6134: testdocu.patch
| File testdocu.patch, 3.7 kB (added by jdetaeye, 1 year ago) |
|---|
-
docs/settings.txt
old new 981 981 982 982 Default: ``None`` 983 983 984 The name of database to use when running the test suite. If a value of 985 ``None`` is specified, the test database will use the name ``'test_' + settings.DATABASE_NAME``. See `Testing Django Applications`_. 984 The name of database to use when running the test suite. 985 If a value of ``None`` is specified and the SQLite database engine is used the 986 tests will use a memory resident database. For all other database engines the test 987 database will use the name ``'test_' + settings.DATABASE_NAME``. 988 See `Testing Django Applications`_. 986 989 987 990 .. _Testing Django Applications: ../testing/ 988 991 -
docs/testing.txt
old new 270 270 271 271 $ ./manage.py test animals.AnimalTestCase.testFluffyAnimals 272 272 273 Understanding the test output 274 ----------------- ------------273 The test database 274 ----------------- 275 275 276 When you run your tests, you'll see a number of messages as the test runner 277 prepares itself:: 276 Tests that require a database (namely, model tests) will not use 277 your "real" (production) database. A separate, blank database is created 278 for the tests. 278 279 279 Creating test database... 280 Creating table myapp_animal 281 Creating table myapp_mineral 282 Loading 'initial_data' fixtures... 283 No fixtures found. 280 Regardless of whether the tests pass or fail, the test database is destroyed when 281 all the tests have been executed. 284 282 285 This tells you that the test runner is creating a test database -- a blank, 286 from-scratch database that it will use for any tests that happen to require a 287 database (namely, model tests). 283 By default this test database gets its name by prepending ``test_`` to the value 284 of the ``DATABASE_NAME`` setting. When using the SQLite database engine the tests 285 will by default use a memory resident database (i.e. ``:memory:``). 286 If you want to use a different database name, specify the ``TEST_DATABASE_NAME`` 287 setting. 288 288 289 Don't worry -- the test runner will not touch your "real" (production)290 database. It creates a separate database purely for the tests. This test291 database gets its name by prepending ``test_`` to the value of the292 ``DATABASE_NAME`` setting. If you want to use a different name, specify the293 ``TEST_DATABASE_NAME`` setting.294 295 289 Aside from using a separate database, the test runner will otherwise use all of 296 290 the same database settings you have in your settings file: ``DATABASE_ENGINE``, 297 291 ``DATABASE_USER``, ``DATABASE_HOST``, etc. The test database is created by the … … 306 300 307 301 .. _settings: ../settings/ 308 302 303 Understanding the test output 304 ----------------------------- 305 306 When you run your tests, you'll see a number of messages as the test runner 307 prepares itself. You can control the level of detail of these messages with the 308 ``verbosity`` option on the command line:: 309 310 Creating test database... 311 Creating table myapp_animal 312 Creating table myapp_mineral 313 Loading 'initial_data' fixtures... 314 No fixtures found. 315 316 This tells you that the test runner is creating a test database, as described 317 in the previous section. 318 309 319 Once the test database has been created, Django will run your tests. 310 320 If everything goes well, you'll see something like this:: 311 321 … … 349 359 feature is useful if you're using the test-runner script in a shell script and 350 360 need to test for success or failure at that level. 351 361 352 Regardless of whether the tests pass or fail, the test database is destroyed when353 all the tests have been executed.354 355 362 Testing tools 356 363 ============= 357 364
