Hi Russ, Thanks for your reply ;)
I think it could be easier for me to argue my POV in a discussion instead of "presentation"-like description. On Sep 4, 8:18 pm, Russell Keith-Magee <[email protected]> wrote: > I echo Malcolm's comment when he wontfix'd the ticket a year ago. The > patch forces a artificial naming convention. As a as a workaround for > that naming convention, you proposed a glob setting. Yes,it does. But it does not force to use it. After applying the patch one could just keep the test site organization already in place. Also, any unit test framework applies some conventions (either naming or organizational), don't you agree? > > All of this seems to be in aid of avoiding one of three very simple > existing solutions: > * using import statements in test/__init__.py That is the reason of the patch - to be able to have test modules been automatically found. But this is going to be a possibility, not a limitation. > * defining a suite() that includes a test discovery mechanism that > includes the tests you want Indeed, that is the strongest argue against the patch. Personally I have the following troubles with this approach (any help would be highly appreciated): 1. AFAIU Django is going to detect and use the suite() method in `tests' module. Thus, we have to have that suite() available inside the tests/__init__.py 2. Any test discovery code I can imagine will import python modules (e.g. test_*.py files) from inside the tests/ folder - thus it will cycle been discovering modules from inside their importing (at least I've got that behavior when tried to do so) 3. A new feature: when suite() is provided, right now Django is unable to call a single test case form that suite (I don't know why - seems to be python unittest's specifics). With the way the provided patch does its auto-discovery, each test case is available to be run in single mode. > * writing a custom test runner that discovers tests with a particular > file prefix Yes, but other applications could provide (and enforce usage of) their own test runners - in my case that is GeoDjango. > I can tell you're enthused by the idea - working on a patch for a year > even after it's been wontfix'd shows some serious dedication. However, > that doesn't change my review - I'm still wontfix on this idea. Well, I'm not been working on a patch for a year ;) I'm working on a project which has a lot of modules and tests inside modules, thus the proposed approach really helps me a lot. > > Yours, > Russ Magee %-) Regards, Evgeny Sizikov --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
