I'm keen to try to find some proper ways to fix this, but before I go too deep into the bowels of Django's testing framework, I was wondering what would be the criticisms you'd have about the "solution" I came up with (at the start of this thread)? It sort of works without patching Django, but is it acceptable? and if not, why?
At this stage, it looks good enough to me except for two main points that feel dirty: 1) the test models should be unloaded after the test is run 2) potential conflicts with external apps should be avoided. Any advice/hint welcome ;) Julien On Nov 27, 12:42 pm, Rock <[EMAIL PROTECTED]> wrote: > I took a similar path. I cloned the run_tests function from > django.tests.simple.py and put it in my project directory as > test_setup.py while adding this near the top of the function: > > if settings.TEST_APPS: > settings.INSTALLED_APPS += settings.TEST_APPS > > That at least allows me to define TEST_APPS in my main settings file > for the project and in a location near INSTALLED_APPS so that I am > less likely to introduce unintended collisions. But my approach feels > dirty too. It shouldn't take much work to incorporate a TEST_APPS > construct into the existing test framework. I realize it might be > nicer if each batch of unit tests could define their own set of extra > test models, but I think that a master list of additional test apps > like above has the advantage of simplicity. But I haven't given this a > lot of thought beyond this simple minded hack. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
