Re: how to get the test runner to only rebuild & populate the test_database if it changed?

2011-05-11 Thread Phlip
> Me again. Still helping clients TDD despite obese databases.

[localhost] run: python manage.py test --settings=test_settings my_app
--verbosity=0
--
Ran 2 tests in 0.018s

OK

Eat my vapor trail, b-words! Here's how I did it:

Upgrade the settings.py to use the TEST_NAME option:

DATABASES = {
'default': {
'NAME': 'test_myapp.db',
'TEST_NAME': 'test_myapp.db',
'ENGINE': 'django.db.backends.sqlite3', ...

Then wedge the test runner methods that were destroying and rebuilding
the database:


def setup_databases(self, **kwargs):
from django.db import connections
old_names = []
mirrors = []
for alias in connections:
connection = connections[alias]
# If the database is a test mirror, redirect it's connection
# instead of creating a test database.
if connection.settings_dict['TEST_MIRROR']:
mirrors.append((alias, connection))
mirror_alias = connection.settings_dict['TEST_MIRROR']
connections._connections[alias] =
connections[mirror_alias]
else:
old_names.append((connection,
connection.settings_dict['NAME']))
#connection.creation.create_test_db(self.verbosity,
autoclobber=not self.interactive)
return old_names, mirrors

def teardown_databases(self, old_config, **kwargs):
from django.db import connections
old_names, mirrors = old_config
# Point all the mirrors back to the originals
for alias, connection in mirrors:
connections._connections[alias] = connection
# Destroy all the non-mirror databases
#for connection, old_name in old_names:
#connection.creation.destroy_test_db(old_name, self.verbosity)

from django.test.simple import DjangoTestSuiteRunner

DjangoTestSuiteRunner.setup_databases = setup_databases
DjangoTestSuiteRunner.teardown_databases = teardown_databases

The next thing I'll need to do is rebuild the database only if the
models or .json files change.

I could add that to the wedge methods, above, or I could simply add a
"make" like system to the fabric fabfile.py that runs the test:

def test():
#  TODO  Check file time of test_myapp.db. If it's less than
my_app/models.py
   # or my_app/fixtures/my_app_database.json, rebuild the
db file

_sh('python manage.py test --settings=test_settings my_app --
verbosity=0')

This system now fully exploits sqlite3, especially its ability to
treat a transaction as a virtual ":memory:" database. It does not even
change the file time on the .db file when the tests run.

Could someone better at Django internals than me package this system
up and contrib it?

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

-- 
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.



how to get the test runner to only rebuild & populate the test_database if it changed?

2011-05-11 Thread Phlip
Djangoists:

Me again. Still helping clients TDD despite obese databases.

Right now the test suite takes a minute to build a database with >20
models (and lots of fields in each one), then load a mere 7,000
records. Yes I will cut down on the records, but building the
database, in sqlite3 :memory: mode, is also a big chunk.

So if I built the DB once, then ran a TDD cycle, couldn't the entire
system leave the database in a sqlite3 document, and put transactions
around each test case?

I'm going to copy the TestCase classes into our project, and have my
way with them. But is there an easier way, or has someone already done
this?

(1.2, BTW - the obese database prevents an upgrade to Django 1.3!)

--
  Phlip
  http://c2.com/cgi/wiki?ZeekLand

-- 
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.