Ever tried to unit test custom fields or abstract models? If so, you probably used a solution like [this one](http://djangosnippets.org/snippets/2843/). It surely works, but it has some issues:
1. Runs 'syncdb' several times.
2. It's not automatic. You must add the mixin or copy the code to each of the TestCases.
This test runner adds to INSTALLED_APPS the 'app.tests' package for **each of the specified** apps, **before the 'syncdb' happens**.
This has the [discovery runner](https://pypi.python.org/pypi/django-discover-runner) as a dependency (for 1.5 only, it will be the default in 1.6). However, it comes as a mixin so it should be easily pluggable to other test runners.
If you intend to use the mixin with other runners, note that it imports 'app.tests.models' so it won't work with tests modules (tests.py). Your runner must "use" test packages (like discovery runner).
# USAGE
# in your settings.py:
TESTAPPS_INSTALL = (
'app1',
'app2',
# ...
)
TEST_RUNNER = 'testapp_runner.DiscoverTestAppRunner' # example import path
# extra apps in command line.
# run test for apps 'app1' to 'app4', adding 'app3' and 'app4' to the TESTAPPS_INSTALL setting.
manage.py test app1 app2 app3 app4 --with-test-app=app3 --with-test-app=app4
- django
- testing
- apps
- testrunner
- test-runner
- app-models
**Use Case**: Specify the DB to run tests against. For example, use a legacy DB (un-managed), or a read-only DB where it is un-important to test creation, but important to test connection, trigger functions, and that models match schema.
**Usage**: in DATABASES setting, add:
'TEST' :{
'USEDB': 'your_test_DB_name_here',
}
and setting:
`TEST_RUNNER = 'your_app.test_runner.UseDBTestRunner' `
Advantages over --keepdb:
1. DB specific setting for multi-DB setup (e.g., default can use normal test DB, while legacy can use a pre-existing table).
2. Can specify any DB table, including the one used by the app (for non-destructive tests, or dev DB)
3. Allows testing against DB where creation or copying is prohibitive.