Russ, The method you describe sounds like the preferred way. It's cleaner to add a new test runner module than to modify existing Django code. I really like it.
But as you say, it's not obvious how to do this. I'd like to do a write-up of how this is done, for the common use case where you don't have database creation privileges. Before I dig in and try to figure this out by myself, has anyone out there written a test runner you could share with me? /Martin On Dec 9, 4:50 am, Russell Keith-Magee <[email protected]> wrote: > On Wed, Dec 9, 2009 at 7:22 PM, <[email protected]> wrote: > >> Django allows you to define a custom test runner. Copy > >> django.tests.simple.run_tests() into your own code, removing the calls > >> to create and destroy the test database. Then set TEST_RUNNER in your > >> settings file to point at the new runner. > > Hello! > > I see many similar bugreports and wishes which was closed with this > > proposal. > > > Unfortunately this will not work with recent django versions. > > Errors like AttributeError: 'Settings' object has no attribute > > 'DATABASE_SUPPORTS_TRANSACTIONS' > > Ok - I oversimplified slightly. You can't just delete the call to > create the test database. You need to replicate some of the logic that > the backend that establishes the extent of transaction support on your > database of choice. > > My point still stands - Django ships with an ability to control and > customize the testing process. You just need to pick the > customizations that are required by your particular deployment > scenario. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
