On Tue, Jun 15, 2010 at 9:46 AM, Arthur Koziel <[email protected]> wrote: > Hey there, > > I'm making some progress on the app loading gsoc project. I'm still in the > process of writing tests for the AppCache. It took me longer than I've > thought. However, I'm really confident that I'll finish the testing stuff > this week and move on to writing the new App class. There are still some > things that I don't understand. I've written them down below, and would > really appreciate it if someone could take a look at them. > > 1. The AppCache is initialized early when the test cases are run, which means > that not everything can be tested properly. I'm currently using a standalone > script, but it would be better if Django's test runner could run the tests > without initialized the AppCache. Are there already plans to change this > (maybe in the testing improvement gsoc project?) >
So my one thought here is to allow the AppCache to work with a custom installed apps list, rather than a settings provided one, that way it can be formally unittested, without respect to it's enviroment (the issue here is the borg pattern, as you mention, frankly I think that code is doing more harm than good if it impedes good testing, as you say, who is actuall instantiating app caches?). > 2. Some methods are using a lock in order to be thread-safe[0]. I haven't > found a good way to test this nor can I reproduce the threading problems when > removing the locks. Is there a good way in Python to test concurrency > problems? (should such problems even be tested at all?) > Concurrency problems are hard, and it's not just a Python problem. Frankly, I suspect some of the methods are threadsafe even wtihout the locks, but of course I'm not sure I can prove that. > 3. Changeset 5919[1] modified the AppCache class to use the Borg/Monostate > pattern. However, I haven't found a single case where there is more than one > instance created. Does someone know a case? > > 4. Also in the same changeset, the 'nesting_level' and 'can_postpone' > variables were introduced. These fixed a problem where the package is still > being imported by Python and the model module isn't available yet. Again, I > couldn't reproduce this problem. As Malcolm Tredinnick notes in the comments > to Ticket 1796 [3], writing a test case for this is difficult as the problem > is dependent on hardware/OS/etc. Has anyone here run into similar problems or > can reliably reproduce the error? (and is there any way to contact Malcolm?) > > 5. The app_errors attribute/the get_app_errors method doesn't seem to be used > at all. Is there a reason why it's still there? > > Arthur > > [0]: > http://code.djangoproject.com/browser/django/trunk/django/db/models/loading.py#L124 > [1]: http://code.djangoproject.com/changeset/5919 > [2]: http://code.djangoproject.com/ticket/1796#comment:65 > > > -- > 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. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
