0

In order to pass the unit tests running on a fresh install of django trunk (1.4c1), it is necessary to add in a 'dummy' other database in settings.py, like this:-

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': 'mydb',                      # Or path to database file if using sqlite3.
        'USER': 'myuser',                      # Not used with sqlite3.
        'PASSWORD': 'mypassword',                  # Not used with sqlite3.
        'HOST': 'localhost',                      # Set to empty string for localhost. Not used with sqlite3.
        'PORT': '5432',                      # Set to empty string for default. Not used with sqlite3.
    },
    # dummy sqlite3 database created to pass django's builtin unit tests
    'other': {
        'ENGINE': 'django.db.backends.sqlite3'
    }
}

Why is that so and what is the purpose of this "ensure_defaults" function in django/db/utils.py's ConnectionHandler class?

Just curious to understand django at a deeper level...

Calvin Cheng
  • 35,640
  • 39
  • 116
  • 167

2 Answers2

1

Django 1.4 adds a new subclass of TestCase called SimpleTestCase, that allows you to run tests that don't need a database connection. My guess is that django.db.backends.dummy is being used as a sort of default database in this scenario, as ensure_defaults sets this as the database, if no database is specified.

However, as to why you have to add an additional database engine to make your tests pass, I can't say. There's absolutely no mention of this in the release notes for 1.4, and it doesn't sound right like something Django would require. It's possible this may be a bug (1.4 is only in release candidate stage right now, so it's certainly open to bugs), but without additional confirmation, there's no way to know.

I'm not in a position to test it myself right now, but I will try later today.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • yes, it's a bug. see http://groups.google.com/group/django-developers/browse_thread/thread/e30a9dcc5685954c/5cff8b0e820c1958?show_docid=5cff8b0e820c1958 – Calvin Cheng Mar 07 '12 at 23:33
1

If you're running Django's own unit tests, that means you want to test Django itself. One element of Django itself is the multiple database support - so, not unnaturally, the built-in tests test the multi-db support. In order to test that, you need to configure multiple databases.

Of course, in the normal run of things you would never need to run Django's own unit tests. You'd only do that if you were actually contributing to Django itself. You should rely on the fact that they pass already, and just test your own code, not Django.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895
  • Yup. I understood that part about not needing to care about django's own unit tests. I was just curious about the inside workings of django, which is why I am checking out this little problem. Not discounting that if I can contribute to fix something broken in django, I will be more than happy to do so. It's a bug - http://groups.google.com/group/django-developers/browse_thread/thread/e30a9dcc5685954c/5cff8b0e820c1958?show_docid=5cff8b0e820c1958 – Calvin Cheng Mar 07 '12 at 23:34