@@ -301,12 +301,12 @@ Regardless of whether the tests pass or fail, the test databases are destroyed
301
301
when all the tests have been executed.
302
302
303
303
By default the test databases get their names by prepending ``test_``
304
- to the value of the :setting:`NAME`` settings for the databased
304
+ to the value of the :setting:`NAME` settings for the databases
305
305
defined in :setting:`DATABASES`. When using the SQLite database engine
306
306
the tests will by default use an in-memory database (i.e., the
307
307
database will be created in memory, bypassing the filesystem
308
308
entirely!). If you want to use a different database name, specify
309
- `` TEST_NAME` ` in the dictionary for any given database in
309
+ :setting:` TEST_NAME` in the dictionary for any given database in
310
310
:setting:`DATABASES`.
311
311
312
312
Aside from using a separate database, the test runner will otherwise
@@ -325,6 +325,58 @@ control the particular collation used by the test database. See the
325
325
:ref:`settings documentation <ref-settings>` for details of these
326
326
advanced settings.
327
327
328
+ .. _topics-testing-masterslave:
329
+
330
+ Testing master/slave configurations
331
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
332
+
333
+ .. versionadded:: 1.2
334
+
335
+ If you're testing a multiple database configuration with master/slave
336
+ replication, this strategy of creating test databases poses a problem.
337
+ When the test databases are created, there won't be any replication,
338
+ and as a result, data created on the master won't be seen on the
339
+ slave.
340
+
341
+ To compensate for this, Django allows you to define that a database is
342
+ a *test mirror*. Consider the following (simplified) example database
343
+ configuration::
344
+
345
+ DATABASES = {
346
+ 'default': {
347
+ 'ENGINE': 'django.db.backends.mysql',
348
+ 'NAME': 'myproject',
349
+ 'HOST': 'dbmaster',
350
+ # ... plus some other settings
351
+ },
352
+ 'slave': {
353
+ 'ENGINE': 'django.db.backends.mysql',
354
+ 'NAME': 'myproject',
355
+ 'HOST': 'dbslave',
356
+ 'TEST_MIRROR': 'default'
357
+ # ... plus some other settings
358
+ }
359
+ }
360
+
361
+ In this setup, we have two database servers: ``dbmaster``, described
362
+ by the database alias ``default``, and ``dbslave`` described by the
363
+ alias ``slave``. As you might expect, ``dbslave`` has been configured
364
+ by the database administrator as a read slave of ``dbmaster``, so in
365
+ normal activity, any write to ``default`` will appear on ``slave``.
366
+
367
+ If Django created two independent test databases, this would break any
368
+ tests that expected replication to occur. However, the ``slave``
369
+ database has been configured as a test mirror (using the
370
+ :setting:`TEST_MIRROR` setting), indicating that under testing,
371
+ ``slave`` should be treated as a mirror of ``default``.
372
+
373
+ When the test environment is configured, a test version of ``slave``
374
+ will *not* be created. Instead the connection to ``slave``
375
+ will be redirected to point at ``default``. As a result, writes to
376
+ ``default`` will appear on ``slave`` -- but because they are actually
377
+ the same database, not because there is data replication between the
378
+ two databases.
379
+
328
380
Other test conditions
329
381
---------------------
330
382
@@ -1349,17 +1401,23 @@ set up, execute and tear down the test suite.
1349
1401
1350
1402
Creates the test databases.
1351
1403
1352
- Returns the list of old database names that will need to be restored
1404
+ Returns a data structure that provides enough detail to undo the changes
1405
+ that have been made. This data will be provided to the ``teardown_databases()``
1406
+ function at the conclusion of testing.
1353
1407
1354
1408
.. method:: DjangoTestSuiteRunner.run_suite(suite)
1355
1409
1356
1410
Runs the test suite.
1357
1411
1358
1412
Returns the result produced by the running the test suite.
1359
1413
1360
- .. method:: DjangoTestSuiteRunner.teardown_databases(old_names)
1414
+ .. method:: DjangoTestSuiteRunner.teardown_databases(old_config)
1415
+
1416
+ Destroys the test databases, restoring pre-test conditions.
1361
1417
1362
- Destroys the test databases, restoring the old names.
1418
+ ``old_config`` is a data structure defining the changes in the
1419
+ database configuration that need to be reversed. It is the return
1420
+ value of the ``setup_databases()`` method.
1363
1421
1364
1422
.. method:: DjangoTestSuiteRunner.teardown_test_environment()
1365
1423
0 commit comments