On Sat, Jan 31, 2009 at 9:53 AM, Jarkko Laiho <jarkko.la...@gmail.com>wrote:
> > I'm developing a simple Ajax backend that presently only consists of > one URLconf and a single view. I'm trying to do test-driven > development and have a few initial tests present, but 'manage.py test' > is crapping out on me. > > Initially, I got ImproperlyConfiguredError for not having DATABASE_* > configured in the settings file. Googling this brought me to > > http://docs.djangoproject.com/en/dev/topics/testing/#using-different-testing-frameworks > and Russell Keith-Magee's advice on the issue (e.g. > > http://groups.google.com/group/django-users/browse_thread/thread/fe90a261293ea995 > and > http://groups.google.com/group/django-users/browse_thread/thread/d3cac9794c5e59f1 > ), suggesting creating a custom test runner by copying the code of the > default runner w/o the test database creation, and then defining > TEST_RUNNER in the settings file. > > That's what I did, but a different set of errors appeared. First, > here's the code of my custom run_tests, with the database bits > commented out. (Based off trunk r9800) > > [snip good debug info] > I went as far as commenting out all "django-specific" bits of the test > runner, removing the imports from django.* to make sure that run_tests > was just using the unittest functionality, and added a single test > manually to the suite variable, but the same NotImplementedError came > up. Looks like the empty DATABASE_* settings are causing something > somewhere in the chain to go to the BaseDatabaseOperations class and > call its methods, all of which of course return NotImplementedError. > > This is now well beyond my skills, so I turn to you, the experts. What > is the correct method of creating a custom test runner for testing > Django without a database, and is this different pre- and post-r9756, > since at least the error message is completely different? > What's causing the call to the database is that you are apparently (based on the tracebacks) using a django.test.TestCase, not a basic unittest.TestCase. The django.test.TestCase class assumes the database exists. The details of how the database is kept "clean" between different django.test.TestCase runs differ pre- and post-r9756, so that is why you see different errors for the different levels. The doc about defining a different test runner starts with the assumption you are not using Django's test framework -- I read that to mean you are not using django.test.TestCase tests, for example. You can't just rip out the database-create/destroy parts of the test runner and still expect to run django.test.TestCase tests to still run, since they do assume a database exists. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
