On 7/17/07, Manoj Govindan <[EMAIL PROTECTED]> wrote: > > Hi Russ, > I *did* try loading fixtures by making use of Django's own TestCase. > > However, this proved to be too expensive in terms of time taken to run > tests given that: > 1) Deriving test classes from Django's TestCase slows execution down > considerably, even in the *absence* of fixtures.
This is because Django's test case flushes the database between each test. This is the right thing to do for testing purposes, because it removes the possibility of crossover effects in the testing process, but it does impose a slowdown (because flushing is an expensive operation). This has been discussed on the developers list. We would very much like to speed up test operation, but > 2) As my test data is static and unchanging there is no reason to load > it before each test case/method. IMHO, this is a dangerous statement to make - what if one test makes an (mistaken) change in the database? Then all your subsequent tests will fail. Or worse still - what if one test makes a change to the database that masks an error in a subsequent test? Under this circumstance, you run your tests and get no test errors, but in fact there are errors in your code. > How can I load static, one-time-load data for use with test cases > without using either Django's TestCase or initial_data? I would suggest writing (and installing) a custom run_tests method. In your run_tests implementation, install your fixture, then call the existing run_tests implementation. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
