Django SQLite testing oddity: Different path of execution?

Question

This is merely a theory that I would like to figure out based on others feedback and perhaps similar experiences.

Been using mySQL for running tests, but of course an in-memory SQLite database is much faster. However, it seems to have run into some problems.

When DATABASE_ENGINE is set to use django.db.backends.sqlite3 and I run manage.py test, the output is not as hoped:

(Removed most lines, but pointing out interesting points of failure)

$ python manage.py test
Traceback (most recent call last):
  File "manage.py", line 12, in 
    execute_manager(settings)
  File "/Users/bartekc/.virtualenvs/xx/lib/python2.6/site-packages/django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "/Users/bartekc/domains/xx/xx/associates/yy/models.py", line 51, in 
    class AcvTripIncentive(models.Model):

  # First interesting failure
  File "/Users/bartekc/domains/xx/xx/associates/yy/models.py", line 55, in AcvTripIncentive
    trip = models.OneToOneField(Trip, limit_choices_to={'sites' : Site.objects.get(name='ZZ'), 'is_active' : True,})

  # Next interesting failure
   File "/Users/bartekc/domains/xx/xx/associates/yyz/models.py", line 252, in 
    current_site = Site.objects.get_current()

There are multiple failures like this but just pointing out a couple. The problem is obvious. The Site model has no actual data, but the files contain code that try to fetch the current, or specific instances under the Site model.

Now, I can think of an easy solution: That OneToOneField should be switched to use a function with limit_choices_to, and the second one the same. The functions are then called when required, not on initial scanning of the file by Django.

However, my actual question is: Why does this happen with SQLite and not mySQL?. Is there a different way the two database engines process through tests? I wouldn't think so, since Python is doing all the compiling of the models.

What exactly is happening here?

Cheers.

Answer 1

Is there some reason you are not mocking access to the database? Your UT boundary gets enormously wide when you add a database (no matter what database) to the mixture. It starts to look more like an integration test rather than a unit test.