Wow... lots of stuff here. > >> This is > >> because SQLite uses an in-memory store, so it isn't disk bound; > >> Postgres is disk bound, but is able to use transactions to optimize > >> test setup and teardown; MySQL is also disk bound, but doesn't support > >> transactions, so there are a lot of "CREATE DATABASE; do one thing; > >> DESTROY DATABASE" calls in the lifepan of the test suite.
Sounds like my testing databases should live on a ramdisk if at all possible to speed things up. > >> The biggest single problem that I am aware of is that even > >> though tests are composed in TestCases that have common setup/teardown > >> routines, each test is handled separately. > However, if we determine that unittest2 will give us a major > performance boost, I have no particular objection to shipping > unittest2 with Django as a support mechanism for Python 2.4-6 (in the > same way that we ship a copy of doctest.py). It sounds like integrating unittest2 would be a pretty viable way to use existing code to help us speed up the testing framework. It seems like a far better solution than the custom thing I was proposing above. What steps would be necessary to make a formal decision about unittest2? Do we need some specific proof of concepts to show that it's faster? -Paul -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
