On Sun, Apr 27, 2008 at 12:27 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > In particular, I thought I had remembered some discussion a while back > about how expensive different test packages were, since each package > requires a setup/teardown of the database. Normally this is an > acceptable inconvenience, but it becomes a burdern for tests that > don't actually use the database.
Test performance is a long standing problem (ticket #4998 for those keeping track). I'm open to any suggestions to improve things on this front. One of the GSOC projects made an interesting suggestion; more details on that below. > So, my question is this: how expensive is it, really, to setup and > teardown the database and whatnot, with two separate packages? - The slow operation is resetting the database. As far as I know, there isn't much that can be done about this. No matter which way you do it, deleting a whole lot of data then re-establishing database structure is an expensive operation. However, it is also an essential operation for certain tests because guaranteeing initial test state can only really be done if you have a clean slate to start with. - The database reset is only used by django.test.TestCase. If you are using raw unittest.TestCase or doctests, the database isn't flushed, and so they can run quite quickly. - There is nothing stopping you from mixing and matching doctests, raw unittest.TestCases and django.test.TestCases in a single test module. The one immediate area for improvement is to cover the case where you need the django.test.TestCase capabilities (fixtures, test client, assertions etc), but don't need the database to be reset (because the tests aren't modifying the test data). One idea stemming from this year's GSOC proposals is to add a decorator (or some similar mechanism) to disable the database reset on a per-test basis and/or adding a class variable to disable the reset for all tests in the class. This would allow you to use the Django test cases to set up data, but speed up the tests for those cases that can support the optimization. > Is it > enough to merit rolling all these tests into one package, or would it > be worth it to maintain the separation of concerns? At the top level, you have regression tests for file uploads, so it makes sense that they are all in a single package. However, that doesn't preclude some internal organization. Having multiple test classes in a single tests.py file is one way to do this (and there are already a few examples of this in the regression tests for the fixtures and test cases). If you have a lot of test cases and a single test file gets too big, you can also consider splitting up the test module into submodules. Rather than a single tests.py file, make at tests directory containing a bunch of .py files containing tests. Doctests use the __tests__ variable to find subtests; unittests can be broken up by putting 'from submodule import *' into the __init__.py file in the tests directory. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
