Add keepdb option to test command

[Phui Hock]

Allow user to keep the test database after running all the test cases for later inspection.

[Russell Keith-Magee]

I'm going to mark this wontfix, because it wont work anywhere near to how you probably expect it to work:

1) If you have N tests, you won't be able to get any useful information from the state of the database for tests 1 to N-1. The test database is flushed at the start of each test, so preserving the test database at the end of the test run will only show you the state of the database at the end of the very last test.
2) If you're using a Django test case, you won't even be able to get useful database state information out of the very last test, either. The teardown for a Django test case does a transaction rollback, so at the end of the test run, the database is empty.

So, --keepdb would only be useful for the very last test, if and only if that test is a doctest, raw unit test, or TransactionTestCase. Given how difficult it is to explain the limited cases where this option actually will do something useful, I'm not especially inclined to include it in trunk.

[Phui Hock]

Would you be kind enough to point me to the right direction where the test database is flushed at the start of each test?

AFAIK, the only time the test db is flushed is when all tests are run, in django.test.simple.run_tests(). I commented os.remove(test_database_name) from django/db/backends/sqlite3/creation.py and ran the unit tests (manage.py test auth sites sessions). All test data are retained in the test db.

I reckon that test data should be setup in a way that is independent of the previous tests. I find it useful to inspect the test db as part of the debug process when test cases fail.

[Russell Keith-Magee]

Each test *is* independent and starts with a clean database, which is exactly why --keepdb won't work. *All* the test data isn't retained in the test db - only the test data *from the last executed test* is retained, unless you're running doctests or standard unit tests, in which case it gets really messy to determine exactly what will be in the database at the end of the test run.

As for the code that does this: you're looking for TransactionTestCase._fixture_setup() and TestCase._fixture_teardown() in django.test.testcases.

If you want to inspect the test db during test execution, I recommend setting a debugger breakpoint in the test case you want to inspect.