Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#1763 closed defect (wontfix)

Patch to enable in-memory testing of Django applications

Reported by: crankycoder@… Owned by: adrian
Component: Database layer (models, ORM) Version:
Severity: normal Keywords:
Cc: gabor@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Currently, Django doesn't have a nice way of unit-testing individual applications quickly it takes a long time to drop/recreate the backing database. There are a number of scripts on the web that *almost* let you replace the database with a SQLite in-memory database, but it doesn't work in all cases due to some tricky import problems in Django.

Basically - after the MR branch was merged, the following idiom crept into a lot of the Django code:

from django.db import connection

Unfortunately, in Python, that means that every module that invokes that line will create a module local reference to the connection. If the db module is reloaded with a sqlite in-memory database, all of the caller of "from django.db import connection" will *not* get the new database connection.

I have a patch for Django that will let you cleanly replace the django.db module in one shot.

Attachments (4)

unittest.patch (18.7 KB) - added by crankycoder@… 9 years ago.
Patch to Django to let you replace the django.db module cleanly to facilitate unit testing of applications
test_env.py (1.7 KB) - added by crankycoder@… 9 years ago.
A
test_env.2.py (1.7 KB) - added by crankycoder@… 9 years ago.
A module that has an init_ramdb() function that will replace your database with a SQLite memory version
db_fix.patch (21.6 KB) - added by crankycoder@… 9 years ago.
Updated the patch sync with django svn head at revision 3046

Download all attachments as: .zip

Change History (9)

Changed 9 years ago by crankycoder@…

Patch to Django to let you replace the django.db module cleanly to facilitate unit testing of applications

Changed 9 years ago by crankycoder@…

A

Changed 9 years ago by crankycoder@…

A module that has an init_ramdb() function that will replace your database with a SQLite memory version

comment:1 Changed 9 years ago by crankycoder@…

Sorry for the double attachment, they're the same file, but I hit enter by accident and submitted test_env.py without a comment.

Here's a sample usage of the test_env module.

     13 def test_db():
     14     '''
     15     Test that the enviroment has a reference to the current database
     16     connection
     17     '''
     18     test_env.init_ramdb()
     19
     20     today = datetime.date.today()
     21     c = Contact(first_name='Victor', last_name='Ng', date_created=today)
     22     c.save()
     23
     24     cur = django.db.connection.cursor()
     25     cur.execute("select first_name, last_name, date_created from travel_contact") #  where date_created = '%s'" % (toda        y,))
     26     rows = cur.fetchall()
     27     assert len(Contact.objects.all()) == 1
     28     assert len(rows) == 1
     29     row = rows[0]
     30     assert row[0] == 'Victor'
     31     assert row[1] == 'Ng'
     32     assert row[2] == today
     33
     34     test_env.init_ramdb()
     35
     36     cur = django.db.connection.cursor()
     37     cur.execute("select first_name, last_name, date_created from travel_contact where date_created = '%s'" % (today,))
     38     actual = len(cur.fetchall())
     39     expected = 0
     40     assert actual == expected

comment:2 Changed 9 years ago by Gabor Farkas <gabor@…>

  • Cc gabor@… added

Changed 9 years ago by crankycoder@…

Updated the patch sync with django svn head at revision 3046

comment:3 Changed 9 years ago by Link

  • Type enhancement deleted

comment:4 Changed 9 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed
  • Type set to defect

Replacing the django.db module is very hackish and not Pythonic; we shouldn't encourage that.

comment:5 Changed 9 years ago by crankycoder@…

I hope this doesn't sound snippy - but how should people unit test their Django application then?

Note: See TracTickets for help on using tickets.
Back to Top